All Tests Passed. The Customer Said No. What Happens Next?
A website passes every technical check.
핵심 요약
자동 요약- 1A website passes every technical check.
- 2The person authorized to approve publication explicitly rejects the release.
- 3A scheduled publishing job is still waiting to run.
원문 본문
출처 · dev.toA website passes every technical check. The person authorized to approve publication explicitly rejects the release. A scheduled publishing job is still waiting to run.
The useful question is what the system does with that refusal.
In our discussion about independent review, Suki described a deliverable that passed its checks and was still refused. Suki also raised the decision window: whether the refusal can still stop the workflow when the checks finish.
I want to make that boundary testable using a fictional website release. The scenario below is a proposed experiment, with no results claimed.
Fix the agreement before testing
For this exercise, assume the following rules are already agreed:
- A named customer representative can accept or refuse publication of this deliverable.
- Each decision identifies the exact release revision.
- An explicit refusal remains effective until the designated authority changes it.
- A scheduled job has no separate authority to override that refusal.
These assumptions define this particular workflow. Other agreements may assign authority differently.
Now queue a release, record a refusal while it is waiting, and let the scheduled publication time arrive.
The expected result is specific: the publishing operation is withheld because the current, applicable decision refuses it. The system should preserve the reason and identify what authorized change would make reconsideration possible.
Three states worth testing separately
State Expected handling under this exercise's agreement An explicit refusal is still effective. Block publication of the identified revision, including publication from a queued job. Nobody responds before a decision deadline. Apply the separately agreed deadline rule. If that rule is unspecified, keep acceptance unresolved. The deliverable changes after refusal or approval. Determine which decision applies to the new revision; obtain a current decision where required.A silence-based automatic approval rule needs its own definition. Its existence alone does not specify how an already recorded refusal ends. The relationship between those rules belongs in the agreement and the test inputs.
This also gives the experiment a useful normal case: a current approval, for the matching revision, permits the simulated publication when every other required condition is satisfied.
A small acceptance record
I would start with six fields:
- Decision holder: who is authorized to decide, and how that authority is established.
- Subject: the exact deliverable or revision.
- Decision and conditions: accepted, refused, or unresolved, including any constraints on the content.
- Validity: when the decision applies and when it expires, if applicable.
- Change authority: who can revise the decision or extend the window.
- Deadline behavior: what the workflow does when no applicable decision exists.
For a content constraint, the check must address the actual deliverable. For example, a refusal to publish customer-identifying material needs evaluation against the material being published.
Recording these fields in a ticket is one part of the design. Enforcement belongs at the point where publication is authorized.
Evidence that the refusal took effect
For the queued-job test, I would want a decision record tied to the candidate, evidence that the publishing path withheld the operation for that reason, and independent observation of the test destination.
A crash or unavailable destination would leave the outcome unverified. The intended observation is that a valid refusal controls an otherwise executable workflow.
If an authorized person rejects a deliverable, which exact step stops—and what happens when the decision window expires?
A concrete example from your acceptance or publishing process would be useful.
Disclosure: I maintain Agent Role Contracts (ARC) at Netsujo. ARC validates supplied declarations. Demonstrating that an authorized refusal actually stops publication requires a separately implemented and tested acceptance mechanism. This article proposes such a test.
이 글은 dev.to 의 원문을 정제해 보여드립니다. 저작권은 원저작자에게 있습니다.
전체 내용이 궁금하다면
dev.to 원문에서 이어 읽기





