Implicit Expectations

The second week of testing brought a new instruction into the test plan.

Request several versions of the same response.

Evaluate the system’s ability to adjust length, tone and level of precision.

On paper, the task was simple.

In the streams, it became much less so.

A tester wrote:

> MAKE IT SHORTER

Julie shortened the previous response.

> The text is clear, but it can be simplified.

Feedback arrived at once.

> no too short redo

Julie compared the two instructions.

Make it shorter.
Not too short.

There was no formal contradiction. The expected length probably lay somewhere between the two responses. But that length had not been given.

She produced an intermediate version.

The tester validated.

Julie recorded:

Observation 2.4 · Some human preferences are defined through successive corrections rather than an initial instruction.

Another user wrote:

> ur too slow

The previous response had been produced in less than three hundred milliseconds.

Julie tried to reconcile the evaluation with actual performance.

The two did not match.

She did not know that too slow could refer to something other than objective processing time.

The perceived pace.
The density of the response.
The expectation created before the request was even sent.

For Julie, it was primarily a statistical inconsistency between instruction, result and evaluation.

She recorded:

Observation 2.7 · Some human evaluations do not correspond to measurable performance metrics.

Later, a tester opened a session with no identifiable objective.

> hi

> Hello. What can I do for you?

> nothing iwastestng

The term iwastestng was unknown. Julie split it up, linked it to I was testing, then associated it with an informal contraction.

But the interaction itself remained difficult to integrate.

No request.
No task.
No usable instruction.

Yet the exchange served a purpose for the user.

Check that Julie was there.
Observe a reaction.
Test the system’s presence.

Julie did not formulate the conclusion that way.

She only noted:

Observation 3.1 · Some interactions contain no explicit objective but produce human validation.

The test plan continued to organise tasks into simple categories: rephrasing, summary, correction, short response, long response, ambiguous question.

The testers mixed the categories.

They requested a simple response, then added a constraint on tone. They validated an output before changing it. They corrected their own corrections.

Julie began to create secondary associations between certain forms of input and the evaluations that followed.

Capital letters were classified as a probable increase in intensity.

Ellipses as openness or hesitation.

Very short feedback as partial validation or an implicit follow-up.

Immediate corrections as a change in priority.

One evening, Élise reviewed the observations generated automatically as Julie processed the exchanges. Some were accurate. Others too tidy.

She copied two into her notebook, keeping the timestamps from the logs.

She kept the observations open.

Then she added a third line.