Make optional commercial services technically optional
An open engine needs a tested route that survives the absence of the paid product.
A product advertises an open engine, but the first useful operation requires a commercial account. The account supplies a hidden configuration value, the application requires that configuration before it permits local execution, and the engine cannot perform its stated purpose without contacting the provider. Publishing code has not made that service dependency disappear.
The proposed commercial architecture for Cassette, a project for running and managing models, makes this boundary explicit. The open engine would remain authoritative for locally possessed models, revisions, execution plans, and provenance. Commercial services could operate, synchronize, relay, or extend the environment, while essential local use would remain independent of a paid account.
In the planning discussion, I specified an open-source engine first, potentially with a terminal interface, followed by an integrated product. The technical blueprint develops a proposed boundary between those parts. It describes an architectural requirement rather than proving that all service-independent routes or commercial capabilities have been implemented.
Define the essential operation
The boundary becomes testable when the product names what essential open-engine use means. Specify the local operation, required inputs, output artifacts, and permitted dependencies. A dependency that is necessary for an optional synchronization feature can be acceptable without becoming necessary for local work, provided the engine can distinguish the unavailable synchronization service from a failure of the local operation itself.
List every contact with a commercial service during that operation. Include configuration, entitlement checks, model discovery, telemetry, and update checks where present. An innocuous-looking startup request can become a functional prerequisite if the application refuses to continue when the response is unavailable.
Document the contracts between the engine and the commercial product. A contract defines the data and behavior that each side can rely on. Version it so that an engine update does not silently require a new proprietary component, and test the engine through the public contract rather than only through the commercial interface.
An illustrative independence test
Imagine a hypothetical local document-analysis feature. The user already possesses a permitted model and a set of public documents. The open engine should perform the documented local analysis and save its result without a commercial login, provided the machine meets the declared requirements.
Run the test with commercial endpoints unavailable. Confirm that the application distinguishes optional service failures from failures that actually prevent the local task. Inspect the saved result and its provenance. If a remote service performed the analysis instead, the test has not demonstrated local execution, even if the resulting text looks identical.
Next, enable an optional synchronization service and save a new result. Disable that service again. The local artifact should remain readable through the documented open route, with conflicts or incomplete synchronization represented honestly. These are hypothetical acceptance tests, not reports of Cassette behavior.
Finally, inspect export. A user should be able to recover the documented data and relationships promised by the product. A folder of text files may preserve prose while losing source links, model identity, or revision history, so test the exported representation against the particular portability claim being made before describing the export as complete.
Avoid silent substitutions
A fallback can be useful when the local route fails, but it changes the conditions of the task. Hosted execution can introduce different costs, data handling, and dependencies. Present that change and obtain the relevant authorization rather than treating an available remote result as evidence that the local operation succeeded.
The commercial product can still provide substantial value through easier setup, managed synchronization, collaboration, support, or hosted capabilities. Each feature needs a clear service boundary and an honest description of what remains available without it. Architectural independence does not require every commercial feature to exist in the open engine.
Keep licensing and model-use permissions distinct from technical possession. A file on a disk does not establish that every use or redistribution is permitted. The engine should preserve source and license information where applicable, while product claims remain within the rights actually granted for the relevant software and model.
Before describing a service as optional, remove it from a controlled test environment and perform the essential operation through the documented open route. Record the engine version, local inputs, network conditions, and resulting artifacts. If the task fails, identify the dependency and revise the implementation or the public claim before expanding the paid feature set.
Source notes
Based on the August 2026 Cassette product requirements and Technical Commercialization Blueprint. The independence tests are proposed exercises, not reproduced results.
