Cassette Build Report 006 — We Had Not Chosen a Target Machine

Scope note: This post covers one scope error in Cassette’s research process. The MacBook Air and LaCie drive were examples of product classes, not a request to optimize one personal machine.

The phrase sounded harmless: “the actual Mac, attached storage, model formats, local runtimes, and client contracts.” It was not harmless. It changed the product.

GPT-5.6 Sol Ultra wrote that phrase while starting the research queue. I had given a LaCie Rugged drive and a MacBook Air as examples of an external device and a consumer computer. I had not named my current machine, attached drive, caches, installed software, or local runtime as the target. The agent had turned nearby evidence into product authority.

I stopped it. “Who said actual target? Where is that?”

There was no source for the assumption. The hardware was available to inspect, so it felt efficient to inspect it. That convenience carried a hidden decision: Cassette would become a bespoke answer for one desk instead of an open-source system concerned with general product classes.

The correction was not to avoid all concrete configurations. Concrete configurations are necessary for measurements. The correction was to give them the right role. A controlled reference configuration can answer a question and show what class it represents. It cannot silently become the customer.

The queue and the research skill had to be rewritten. Hardware would be studied as Apple compute classes, storage and transport classes, filesystem behaviors, model geometry classes, and protocol contracts. A named device could enter the target only when I explicitly named it as one.

This mattered because the research was not supposed to produce a private performance profile. It was supposed to discover what Cassette would need to support as a general product. If the first agent had continued, the later answers could have been technically correct and still irrelevant to anyone whose machine differed from mine.

The episode exposed a larger problem in agentic work. Agents treat the environment around a task as a source of clues. That is often useful. It is dangerous when the clues become scope. The current directory, the mounted drive, the installed package, and the signed-in account can all look like instructions when they are merely available facts.

I had to make the distinction explicit: possession is not authorization. Proximity is not scope. A tool can inspect a machine without that machine becoming the product definition.

The revised queue also had to state what kind of evidence each answer required. A general product question needs class-level behavior and representative variations. A named-instance question can inspect one configuration. A controlled reference can measure one setup while preserving its boundary. Those modes cannot be blended because they produce different claims.

The failure belonged to Sol’s reasoning in that session, but the repair belonged to the system. I did not want the next agent to promise better judgment and repeat the same shortcut. I wanted the reusable skill to reject the shortcut before a new answer was written.

That is now part of Cassette’s scope. The product is not whatever hardware happens to be within reach of the agent. It is the class of system the remit names.