---
title: "Business Analyst — Praxis"
route: "/platform/ba"
template: platform-component
intent: "Turn product intent into accepted requirements another role can open."
parent: "/platform"
primaryCta: { label: "Read the BA guide", href: "/docs/plugins/ba" }
description: "The Business Analyst role turns a raw request into typed, traceable requirements and a work-package a team can commit to. The most mature role in Praxis today."
schemaType: WebPage
hero:
  eyebrow: "Stage"
  headline: "Business Analyst harness: turn intent into requirements another role can accept."
  sub: "The Business Analyst turns a raw request into typed, traceable requirements and a work-package the rest of the team can commit to — and keeps acceptance visible for the next role."
  primaryCta: { label: "Read the BA guide", href: "/docs/plugins/ba" }
  secondaryCta: { label: "Docs", href: "/docs" }
maturity: beta
sections:
  - { id: pain, kind: pain, heading: "What the Business Analyst does" }
  - { id: input, kind: explanation, heading: "The input that needs a decision" }
  - { id: capabilities, kind: cards, heading: "Capture, review, and hand off scope" }
  - { id: output, kind: flow, heading: "What it hands off" }
  - { id: handoff, kind: explanation, heading: "Going deeper" }
  - { id: access, kind: cta, heading: "Try it on your backlog" }
---

## What the Business Analyst does

You receive a request that is not yet a specification. The BA harness helps capture its original meaning, clarify affected behavior, prepare reviewable requirements and stories, and ask a person to approve a proposed canonical write. The BA creates the initial canonical work package. Architect later enriches that same ID with the technical package.

## The input that needs a decision

A change request, new feature, or bug report starts as evidence of need, not permission to rewrite product rules. Review existing requirements, business rules, acceptance criteria and affected scope before proposing a change. Show the draft and its impact so the owner can accept or revise it.

## Capture, review, and hand off scope

- **Capture** — retain the original request separately from the interpretation.
- **Shape** — prepare a bounded story or requirement with business rules and acceptance criteria.
- **Review** — preview the proposed canonical change, including affected links, before an approved application.
- **Prepare the initial WP** — give Architect accepted scope and a stable package identity, without pretending the technical design is complete.

The filesystem canon method and the currently packaged Epic-to-story workflow are distinct paths. Source-only tools are not implied to ship in the role ZIP; use the [BA guide](/docs/plugins/ba) for the installed workflow.

## What it hands off

Architect opens the accepted scope, linked rules and initial canonical work package in the shared product repository. If a later Runtime execution package is used, map its local identity to this canonical ID rather than assuming they are the same object.

## Going deeper

[BA setup and commands](/docs/plugins/ba) explain which workflow is installed, which files it reads and writes, and when approval is requested.

## Try it on your backlog

Take one disputed request, retain its original wording, and prepare the smallest scope a person can approve.