---
canonicalUrl: "https://www.hoalee.net/specgent/docs/guide/handoff"
title: "Handing off to planning"
description: "What a downstream planning tool consumes from Specgent, and what it never receives."
kind: "doc"
language: "en"
---

# Handing off to planning

## One artifact

Downstream planning consumes exactly one artifact: one accepted specification revision, identified by its revision id\. Which one depends on the slice decision\.

| Feature shape | The artifact to consume |
| --- | --- |
| a reasoned no\-slice decision | the accepted Feature Specification revision |
| sliced | the accepted Feature\-Slice Specification revision, per Slice |

It is not a bundle of the specification, the RFC and whatever else sits beside them: it is one revision, named by id, whose bytes are sealed and immutable\. The contract binds both sides\. Specgent must make that one document sufficient for planning, and the consumer must not reach behind it; a planner that reads the RFC because the specification was thin has changed what the accepted artifact means\. The readiness report names the revision to consume\.

## What the artifact carries

Each specification embeds a portable description section: the material a planner or a tracker needs, in a form that travels\. It is a deterministic projection of the canonical register, not a summary written beside it\. Render drift blocks sealing and acceptance, so the embedded section cannot quietly disagree with the register it came from\.

A presentation profile may reorder headings and map metadata onto your organization’s conventions\. It may not create canonical meaning, weaken traceability, invoke external systems or generate implementation instructions\.

## Copy out, do not push

Specgent does not push portable material to a tracker, open an issue or call any external system\. Copying the embedded section into your tracker is a human action, and it stays one, so no second, drifting copy of the specification appears where the record cannot see it\.

## What a specification never carries

The specification stops at the contract\. A validator checks every sealed artifact for the following classes, and a specification carrying one does not seal:

- task backlogs: implementation plans, task breakdowns, work plans, or checkbox lists that reference file paths;
- source patches, as diff or patch fences;
- estimates, story points or assignees;
- branch naming or commit strategy;
- paths for files that do not exist yet;
- edit instructions such as “change X to Y in Z”;
- exact code symbols to write;
- ordered implementation steps;
- commands to run\.

## Where the boundary sits

Specgent’s readiness vocabulary stops at `development-ready`\. It never reports `implemented`, `test-passing`, `QA-approved`, `deployed` or `released`, because it never observes a build, a test run or a deployment\.

Your planning tool decides how to build the thing\. Specgent decides what the thing is and proves that decision is grounded\. When a built thing is wrong, there is exactly one document to hold it against\.