Skip to content
HumGu
Own projectHumGu's own projectReal editorial work supported by AI

How we checked AI recommendations while working on the HumGu website

In the project for our own website, we used reviews from Claude, Perplexity and Gemini to examine the then-current version of the offer texts — PL 1.2. This example concerns that stage of the work. The recommendations were then compared against the material and HumGu's confirmed scope. The verification was carried out by an AI assistant in a conversation, based on the content and the owner's decisions.

Below we show specific decisions: a suggestion rejected, a clarification adopted and a dependency checked against the sources. This is a record of work done on content, not the implementation of a system at a client.

Task and material

Review 14 pages and modules: the offer, solutions, agents, the Council, contact and the examples. The aim was to refine the business value and readability while preserving the real scope of the offer.

The input material comprised the PL 1.2 content, the owner's decisions and the criteria for assessing the reviews. Three reviews were obtained, followed by three responses to a challenge — a request to defend or correct the objections against specific passages.

Decision criteria

Does the objection concern the text that was supplied? Is the information indicated actually absent? Does the correction preserve the confirmed scope? Does it avoid adding an unagreed function, status or business result?

Decision 1 — reject an attractive-sounding status

One of the reviews recommended replacing the development status with an “operational version” or “pilot implementations”. What had been confirmed was the availability of specific services and the continued development of the solutions, not the platform statuses mentioned.

The suggestion was not implemented. The information about available collaboration and the development of the solution was kept separate. The reviewer withdrew the proposal after the challenge.

Decision 2 — clarify how the result is handed over

The ECOS description indicated a diagnosis and a design of rules, but the agreement on the form of the result could have been announced more clearly.

Before
„The scope of documentation and verification is agreed before we start.”
After
„The scope of documentation, the form in which the result is handed over and the way it is verified are agreed before we start.”

The adopted correction clarifies the collaboration without adding an unagreed report, template or page count.

Decision 3 — check the basis of A dependency

One of the illustrations in the content concerned a fictional service inquiry. A review proposed making the start date and the service window dependent on the number of locations. The example materials did not establish such a rule.

Instead of adding that dependency, what followed from the catalogue was shown: the number of locations changes the selection of the variant, and the variant affects how the price is determined. The date and the device types still require confirmation; the rule of the sales representative's approval remains unchanged.

Outcome

After the reviews, 12 recorded clarifications were introduced in 10 modules, producing PL 1.3. Each one has the passage before the change, after the change and a justification. The full offer, the agents' identities and the Council's proper mandate were preserved.

The value shown by this work is the ability to trace decisions and link a change to its basis. Specific unconfirmed additions were not turned into company promises.

Scope of this example

We show the control of AI recommendations in a real editorial project. Savings in working time, costs or conversion were not measured. The case is not proof of a production integration, of the whole portfolio working, or of independently confirmed quality of all the texts.

In your organisation

In which task should an AI recommendation be checked against sources and rules before it is used? Describe the process and the result you need.

All examples