The “won’t become a product” rule
Declare in writing, before starting, that the arm will not become a product. The declaration is what makes it survive.
A research arm only stays a research arm if you decide, in writing, before you start, that it will not become a product. The declaration is not a vibe. It's a document. It lives in the project brief, it gets cited in the decision log, and it is the first thing you re-read when the first promising result lands.
I wrote Parley's version into 12-Parley/project-brief.md on the day the folder was created. Under the "NOT in scope" block: no real-time production system, no mobile app, no commercial licensing discussions, no dataset marketplace participation, no replacing any QC priority. Five lines. Five lines have done more to protect the project than any other artifact in the repo.
Why the declaration matters
Every research arm, if it works at all, will eventually produce a result that looks like a product. A notebook will hit a number that someone in your inbox will call "interesting." A technique will compose with two others in a way that sketches a roadmap. A friend will say the words "you should ship this." That moment is the test. Without an explicit non-commercial commitment written down before you started, every promising result will trigger a "should we productize this?" cycle.
The cycle is not free. It pulls a week of evenings into market-sizing instead of the next notebook. It re-opens the question of whether the arm is a side project or a stealth startup, and that question, once re-opened, takes weeks to close. It changes how you talk about the work — which changes what you publish, which changes what you learn. The cycle does not always end in productization. Most of the time it ends with the arm exactly where it started, minus the month you spent debating it.
Parley's roadmap calls for one published notebook per month. A single "should we productize?" detour costs a notebook. Two of them cost a quarter. That is the actual price tag of not having the declaration written down before you started.
How to write the commitment
Three items, minimum. Adapt the language to your arm; do not skip a line.
1. No commercial licensing discussions. If somebody emails about using the work, the answer is "thanks, the project doesn't license." Not "let me think about it." Not "let's talk." The default response sits in your draft folder and you copy-paste it.
2. No real-time or production system. A research notebook can run for an hour. A demo can be slow. The minute you start optimizing for production latency or uptime, you are no longer running an arm. Parley's brief says it directly: stretch goal is a webcam demo app, and that is the ceiling.
3. No participation in adjacent marketplaces. For Parley, that's dataset marketplaces. For your arm it could be model hubs, plugin stores, or whichever surface in your field invites a small good thing to be packaged and sold. The packaging surface is where arms die.
Write these as a block in your project brief. Date it. Cite it in your decision log on day one so future you can find it. The exact words matter less than the fact that they exist in writing before you have results to be tempted by.
When the rule needs to bend
The rule is a rail, not a wall. There is exactly one legitimate exception: a technique developed in the arm becomes load-bearing for the main work.
Parley's brief contemplates this in the success-criteria line: "≥1 technique developed here that could (in a separate decision) flow into QCaddy." The pose, landmark, and temporal models that sign-language CV depends on are the same family of models QC's cornhole vision pipeline relies on. If a notebook in Parley finds something that genuinely improves QC throw classification, the right move is not to keep it secret. The right move is to flow it across.
That is the entire point of the rule: the flow is a separate decision, logged in a separate decision doc, with its own analysis. It is not a quiet drift from "research notebook" to "QC feature." The decision doc names what's flowing, why it's flowing, what stays in the arm, and what about Parley's character is or isn't being violated. The flow is one-way: technique flows from arm to product. The arm itself stays the arm.
Treat the exception the way airlines treat a deviation from the standard approach: allowed, logged, reviewed, and explicitly closed. If you find yourself making the exception twice in a quarter, the rule isn't working and you need to revisit whether the arm is actually an arm.
Apply this
Open your arm's project brief today. If there isn't one yet, create it before you write any code or open any notebook.
Add a section called "NOT in scope." List at least three things the arm will not become. Be specific. "Not a product" is not a line. "No commercial licensing discussions, no real-time production system, no participation in dataset marketplaces" is a line.
Date the section. Cite it in your decision log on day one. The next time a result tempts you, the cite is the answer. The declaration does the work so you don't have to make the decision under enthusiasm.