Import your product

A team that already has a product needs that product in the model before it can propose changes to it. The import does this without anyone retyping it. You send what your team has already written, and a draft of the product comes back: its directions, the capabilities under each, and the boundaries they are held to.

An import is a proposal, not a write

Importing never changes the model directly. It drafts a baseline, a proposal of its own kind, and the team still has to consent to it. Accepting it records what the product is; it delivers nothing.

Where to start it

An import is how a project begins, so it only goes into a project that holds nothing yet.

• New project → From what you already have, at the organization level. Sending the material creates the project and drafts its baseline together.
• From what you already have on an empty project’s start screen, for a project that already exists but is empty, such as your team’s automatic Default.

What to send

1. A summary of what the product is, in one or two sentences. Everything else is read against it.

2. Up to ten excerpts, about a page each. Each has a title, a kind (doc, code, notes or ticket) and the words themselves. You can also give an optional reference to where it came from; reviewers see it, but unbranch never fetches it.

3. Send it. The draft comes back while you do something else. A page or two takes about twenty seconds. A full set takes about a minute, and occasionally up to three. You can leave the page.

The limits are 16,000 characters per excerpt and 32,000 characters for the summary and excerpts together. The page counts as you type, turns amber at 90% of a limit and blocks at the limit. There is no file upload: paste the words. Preparing material for an import explains what makes a good excerpt and why grouping matters more than anything else.

An import uses the team’s model credits. The page shows the month’s credits and which model the send will use.

After the draft lands

1. Read it against the material. The draft and the material it was written from are on the same page, side by side. About seven in ten imports come back as a draft a person would keep. The rest are wrong in recognisable ways that take a few minutes to fix. See Reviewing a draft.

2. Send it for review. An import into an empty project is never audited, because there is nothing to duplicate, and it says so. Until it is sent, nobody else can see it.

3. The team consents. While a baseline is in review, nothing else may enter review beside it, because the model has to still be empty when the baseline is accepted.

4. Mark what is already delivered. Once the baseline is accepted, its items land as active and its commitment as not started. Start the commitment, then verify it, so what already exists shows as delivered. See Commitments and delivery.

Importing through an agent

A connected agent can do the import with you. It gathers material from the repository you work in and from the files you attach. It asks before reading other connected tools, such as a wiki or an issue tracker. Then it shows you an outline before it writes anything. It writes the baseline itself, so it uses no credits to draft. It never sends the baseline for review: you read it and send it on the web.

The two paths differ in one way. The portal’s import keeps only what the material shows works today and asks about the rest. An agent keeps the product’s concepts whether they are built yet or not, because accepting an import delivers nothing, and the team marks delivery afterwards.