What a production version would add

From prototype to production, in five parts

Each part says what exists today and what a production version would add.

1. 01

   Evidence

   TodayFictional PetHealth sample records, plus whatever the practitioner types or pastes in.

   Would addLive, read-only connections to research, support, analytics, and finance systems, keeping the source of every excerpt.

2. 02

   Drafting

   TodayNine tools. Most run a fixed chain of AI calls, and a person starts each one. Each saved record notes what it was built from, and the tools flag it when one of those changes.

   Would addA history for each saved record, so an earlier version can be compared or restored, shared across a team instead of one browser.

3. 03

   Code checks

   TodayWSJF and RICE scores, the funding cutoff, requirement coverage, the assumption gate, batch load, and dependency order.

   Would addThe same checks, rerun on every regeneration, with failures logged.

4. 04

   Human review

   TodayA person reviews each draft in the browser. Sign-offs are names typed into the tool.

   Would addApprovals by authenticated, named roles, recorded in an audit log.

5. 05

   Export

   TodayA CSV that a person imports into Jira by hand.

   Would addWrite-back to Jira after a signed approval, specified below.

One extension, specified: Jira write-back

Today the last step ends with a CSV someone imports into Jira by hand. Writing straight into Jira is the one place the workflow would act on another system, so it needs the clearest rules. The write would be ordinary code calling Jira’s API. The model’s work ends at a rough draft. People refine the backlog, revising and editing it, and its owner approves the result; the model never decides what gets written.

Input

A batch plan from step 9 that people have refined from the model’s rough draft (features, stories with acceptance criteria, builder-day estimates, batch assignments, and dependency links), plus an approval record: who approved it, when, and which version of the plan.

Owner

The product owner approves smaller work; the product manager approves feature-level work and larger. They approve the refined plan, never the model’s draft.

Permitted actions

Create the epic and its stories, with their fields and dependency links, in one named Jira project. No edits or deletions of existing issues, so it never overwrites refinement people do in Jira later, and no other projects. The access token is scoped to that project and expires when the run ends.

Checks before writing

Code reruns the batch-load and dependency checks, confirms the approval matches this exact version of the plan, and shows a preview of every issue it will create. Any change to the plan after approval voids the approval.

When something fails

Stop at the first failed write, report what was and wasn’t created, and don’t retry automatically. Running it again skips issues that already exist for this plan, so nothing is duplicated.

Record kept

Who approved, when, which plan version, and the Jira issue keys created, in an append-only log.

Success measures

Plans reach Jira with no manual re-entry; no issue is ever created without a matching approval; no duplicates; and the issues in Jira match the approved plan (count, points, and links).

Why code and not an agent: creating issues is a side effect with a fixed shape. Handing it to a model, or routing it through a general-purpose connector, adds ambiguity without adding judgment.

Everything else, in order

Each addition is listed with the problem it would solve. This is the order I’d build them in, though it may be different depending on the levels of approval throughout an organization’s budgeting, planning, delivery, and monitoring queues.

Built from this list so far: out-of-date flags on saved records (October 2026), which solved “when an earlier step changes, later steps aren’t told.” How they work.

The questions this is for

None of this is evidence that the system exists. It’s a way to work through the operating-model questions the prototype raises:

• What context must survive each decision?
• Which actions may be delegated?
• Which conditions should be deterministic?
• Where must a human exercise accountable judgment?
• What evidence must be retained?
• What should cause the system to stop?
• How should post-release evidence challenge the original investment case?

Related: the intake and funding framework proposes the operating model around the tools: where ideas come from, how they're sorted into new initiatives and run work, and how each gets funded.