When is an AI-assisted website improvement actually complete?
Tomohiro Iida ·

When you hand website improvement to AI, the diagnosis arrives quickly. The trouble comes afterward: whether the change really shipped, and what happened to search or enquiries, may never return to the person who asked. An agent reporting PASS is not evidence that anything happened in the outside world.
Key takeaways
- To connect AI delegation to customer outcomes, accept purpose, authority, work performed, observation and effect separately.
- On October 27, 2026, a read-only check of SIGNAL production read the approved goals and stored issues for two of our own sites. Observed implementation and outcome rows were missing. That does not prove the websites were unchanged.
- SIGNAL #778 (observation return, exact-version acceptance, attribution, tenant-private learning) merged at 23:53 JST on October 27 after independent code review and CI. Aggregation #777 merged at 00:04 JST on October 28, and a production deployment containing both completed at 08:19 JST on October 28. Production operation and customer acceptance are unconfirmed.
- ARC PR #81 merged 18 offline synthetic comparison cases, not 18 customer cases. PR #82 and #83 merged designs, not formal proofs. PR #84 merged offline tests for a bounded receipt-signature verifier and grants no runtime authority.
This article records where Netsujo SIGNAL and Agent Role Contracts (ARC) stood in October 2026. Technical observations are from October 27; merge and production status is as of 08:20 JST on October 28. We make no claim of customer impact and no claim of consent to cross-tenant learning.
What SIGNAL is for
Netsujo SIGNAL helps enterprise website buyers discover, understand and compare, then self-select and enquire or order. Investigation goes down to code level and produces an implementable ChangeSpec. Human time is kept for the moments where interaction matters. SEO and AIO are means within that purpose. See the SIGNAL service page.
1. Fix the purpose first
"Raise rankings" and "let a buyer judge that this fits" do not always call for the same work. SIGNAL keeps approved goals in the workspace and ties stored issues to them. On October 27 we called the production read-only get_workspace for two of our own sites and confirmed the approved goals and stored issues could be read.
2. Read authority from a separate document
ARC checks declarations of roles, write scope, handoff and review offline, before execution. v1.0.0 is stable and public in the GitHub repository. A PASS shows only that the declarations do not contradict each other. It does not prove executor identity, actual tool permissions, or what really happened. We covered this in what a PASS means and do not repeat it here.
On October 27, ARC had four merges. PR #81 merged 18 offline synthetic comparison cases. They are artificial cases, not customers. PR #82 merged a design for task-authority assurance. It is a design, not formally proven mathematics. PR #83 revised the native-integration design after external feedback; again only a design merged. PR #84 tested, offline and within a narrow scope, verification of an Ed25519 signature on an approval receipt and of the current subject. It grants no runtime authority.
3. Observe the work separately from the report
In a local, unpublished commit (88220a9, not merged into the public repository) we ran a fictional 50-byte read-and-send against a loopback receiver. The healthy path returned 204. We then produced an HTTP 404 after the receiver had already recorded one effect, and a deny-send case. Replaying in a single process created no duplicate receiver records.
This small test shows that a sender's "failed" and a receiver's "one record" can disagree. It is not exactly-once delivery against an external API, and it is not live ARC enforcement. We do not claim that ARC runtime is technically integrated into SIGNAL; only the design principle carries over. Write the report and the observation on different rows.
4. Observations had not come back
Checking SIGNAL production the same day, we found no rows showing observed implementation or observed outcome. This is not proof that the websites did not change. It means a change may have been made without a record returning to SIGNAL. Diagnosis was there; what followed was blank.
The follow-on work is SIGNAL #778: report, correct and retract an implementation, exact-version acceptance in the portal, measurement attribution, and tenant-private learning. It was merged at 23:53 JST on October 27, after independent code review and CI. Aggregation #777 merged at 00:04 JST on October 28, and a production deployment containing both completed at 08:19 JST on October 28. A completed deployment only means the code is in production. Whether this feedback loop actually runs there, and whether implementation and outcome rows fill in, is not yet confirmed. There is no record of human or customer acceptance.
5. Ask about effect last
Even when an implementation is confirmed, whether search visibility or enquiries rose is a different question. Without tying the shipped version to a measurement window, a change can be credited to the improvement or to chance with equal justification. That is why acceptance is split in five: is the purpose right, is the authority right, was the work done, did the observation return, and was there an effect. One of them being done does not make the others done.
Next
For SIGNAL, confirm that the deployed #778 and #777 actually run, and that production reads show implementation and outcome rows filling in. For ARC, advance the design only as far as proof and tests support. ARC and SIGNAL share review principles but are not technically integrated. We will publish only what we have confirmed.
If you are delegating website improvement to AI, decide first what must come back after implementation; the definition of "done" follows. You can check your current state with the free SIGNAL scan, and try ARC from the public repository.