This page traces a single initiative through the entire chain: from an enterprise persona to a Jira-ready sprint plan. Every handoff below happened through the tools' real same-origin handoffs, one click each. Every step links to the captured run itself, so you are judging real output, not a slideware summary of it. The human work in this chain is the review at each gate; the drafting is the AI's.
PetHealth is fictional. The company, people, source records, metrics, approvals, and operating environment in this example were created for demonstration. The displayed artifacts use the structures produced by the tools and are intended for evaluation.
The example contains four kinds of information: scenario facts (fictional inputs intentionally supplied to keep the test coherent, such as the 22% support-contact baseline), fixture evidence (fictional records with source-like identifiers used to test provenance and propagation), model-generated content (draft requirements, assumptions, estimates, NFRs, risks, and narrative), and deterministic results (selected calculations and structural conditions recomputed in code).
A fixture citation shows that a generated claim was associated with a supplied record. It does not make the fictional claim independently true. The review gates shown in this case are modeled checkpoints, not records of approvals by real PetHealth employees.
PetHealth is a fictional mid-size pet insurer with a real-shaped problem: members don't trust the claims process. Claim-status questions alone account for 22% of all support contacts, members describe the period after submitting a claim as a black hole, and leakage in adjudication quietly erodes margin. The company context, evidence set, and competing priorities are held constant across every tool, which is what makes the chain a fair test: each tool inherits its input from the one before, not from a hand-tuned prompt.
The names are fictional. The runs are not: each artifact below is captured output from the live tool.
Marcus Chen, software engineer and PetHealth member. His quote sets the tone for the whole initiative: "I just want to know it's working." Until he needs it. The card carries his Jobs to Be Done statement, tech comfort across channels, key interactions with friction badges, and the quantified organizational impact of his unmet job.
A stage-by-stage map whose pain clusters become opportunity seeds: structured, exportable statements of where the experience breaks and what it costs.
Each epic carries its riskiest Demand, Feasibility, and Viability assumptions and a benefits-realization plan naming the measurement instrumentation that has to exist. The headline benefit target: claim-status share of support contacts falls from 22% to ≤12%.
Five business cases in a standard format, including the Real-Time Claim Status Tracking case that the rest of this page follows.
A defensible ranking with an explicit funding line. Real-Time Claim Status Tracking clears it, and becomes the epic the delivery half of the chain executes.
The Roadmap: one of the four primary outputs program stakeholders care most about.
The BRD for Real-Time Claim Status Tracking with eight business requirements (BR-01 through BR-08), an assumptions section, and the exec sign-off package.
The delivery plan, and the chain's outbound handoff: a Jira bulk-import CSV with Summary, Issue Type, Epic Link, Priority, Story Points, Sprint, Acceptance Criteria, and Issue Links. The chain ends inside your delivery system, not in a document nobody imports.
This section should be updated as external evaluations occur. Current issues visible in the worked example:
The fastest way to evaluate this system is to open the two or three captured runs above that your role would be accountable for, and ask whether they would survive review in your organization. If the answer is "mostly, and I can see what I'd change," that is exactly the conversation the beta is for.