Scope rails for a research arm

A research arm has no customers, no investors, and no co-founder asking why a sprint slipped. The only thing standing between it and quietly becoming a second startup is a list of things it isn't allowed to be. That list is the scope rails. Written, dated, and sitting in the project doc before the first commit.

What scope rails are

Scope rails are the explicit, written, ahead-of-time enumeration of things the project will not become. They're different from aspiration. An aspiration sounds like "we want to stay small" or "I'm not trying to build a product here." Useful sentiment, zero binding power. The version of you three months in, looking at a working notebook and a tempting expansion, has already forgotten the aspiration.

A scope rail is binding because it's specific and because it's in writing. "Real-time production system" is a rail; "let's keep it research-only" is a wish. The rail names a concrete shape the project could take and forbids it. When the temptation arrives, the rail is the thing you read and decide against.

The discipline isn't writing the rails. It's writing them before you start, when the project doesn't exist yet and the temptation is theoretical. After the project is real, every rail you try to add looks like a fence around something you might want, which is exactly why it should already be a fence.

The Parley scope rails as the worked example

Parley is a side research arm into sign-language computer vision. The rails are in 12-Parley/project-brief.md under "NOT in scope." Five items, copied verbatim from the brief:

- Real-time production system

- Mobile app

- Commercial licensing discussions

- Dataset marketplace participation

- Replacing any QC priority

Real-time production system is on the list because real-time inference is where the engineering cost explodes. Research notebooks tolerate batch-mode and offline evaluation; a real-time system needs latency budgets, runtime constraints, and a deploy story. The day the arm tries to ship real-time is the day it becomes a startup.

Mobile app is on the list because mobile is the second-biggest commitment funnel after real-time. App-store presence, version compatibility, an install loop with real users on real phones — every one of those is a quarter of someone's time, indefinitely. A Kaggle notebook does the same demonstrative work without any of it.

Commercial licensing discussions are on the list because the moment money is on the table, the project is a business. Investors, contracts, IP review, term sheets; the apparatus that follows a licensing conversation is the apparatus of a venture, and the arm doesn't have the capacity for one. If something licensable comes out of the work, that's a CIPHER conversation about a separate venture, not a Parley conversation.

Dataset marketplace participation is on the list because selling datasets is a real business with real ops (licensing, support, versioning, GDPR), and once a dataset is for sale, the work bends toward making it more sellable rather than more honest. Parley publishes; it doesn't sell.

The fifth rail in the brief, "replacing any QC priority," is the meta-rail. It's how the other four get enforced when a tempting opportunity slips past them.

Each rail is on the list because at some point I'd be tempted by it. That's the whole criterion. A rail forbidding something that was never going to happen is decoration.

How to write your own

Three prompts to use when drafting an arm's scope rails. Do them in order, with a real pen or a markdown file, before any code exists.

First: what would tempt you to expand this arm? Not what's likely. What's tempting. The honest answer is usually some version of "if this works, I'd want to ship it as a product" or "if I get traction, I'd raise money." Write the tempting outcomes down. Those are your candidate rails.

Second: what would each expansion cost the main work? Be specific. "A mobile app would take two evenings a week and weekend cycles for App Store reviews." Not "it would distract me." If the cost is vague, the rail is weak. If the cost is specific, the rail is binding.

Third: what's the smallest version of the arm that still does what you wanted? That's the version the rails should leave alive. Anything bigger than that goes on the NOT list. The arm exists to do one thing well; the rails exist to keep it from doing six things badly.

The output is a markdown block called "NOT in scope" that lives in the project's brief or README, with a date stamp and your initials. Treat it like an architectural decision, because that's what it is.

When scope rails get tested

Every promising notebook generates a "should we…?" thought. Every clean result is a doorway. This is good (it's the sign the work is real) and it's also the entire reason the rails exist.

The cadence of the test is roughly monthly. Ship a notebook, see it land, get a thought about extending it, open the project brief, read the NOT list, close the loop. Most months the loop ends there. Occasionally a thought is interesting enough to write into the decision log as "considered, declined, here's why." Very occasionally the thought is interesting enough to be a separate project, in which case it gets its own scope rails before any work starts.

The test is not whether the rails feel restrictive. They will. The test is whether the answer to "should we expand?" was already decided, in writing, before the question came up. If yes, the discipline is working. If no, the rails were too vague and need a rewrite.

Apply this

Pick the side project you're closest to running, or the one you're already running without rails. Spend thirty minutes today writing the NOT-in-scope list. Three prompts: what would tempt you to expand, what would the expansion cost, what's the smallest version that still works.

Commit the list to the project's repo or decision doc with today's date. If there's no project doc yet, write one — a single markdown file with "NOT in scope" as a section is enough. The rail only counts once it's checked in somewhere a future version of you will read it.