Roles and ownership

Praxis separates roles so that speed in one job does not erase ownership in another. Start with the role carrying the decision you need to make today.

Choose the role

If you need to…	Role	The first durable result
Clarify vision, a feature request, a changed requirement, or a client bug	Business Analyst	confirmed CR and versioned requirements
Decide how ready requirements should fit the system	Architect	accepted ADRs and a bounded design package
Change code within approved boundaries	Developer	approved plan, code, and verification evidence
Review one change and its evidence	Quality Harness	persisted review and findings; approved Apply if selected

Ownership map

flowchart TB
  subgraph Canon[Product canon repository]
    BA[Business Analyst harness]
    A[Architect harness]
    REQ[Vision · CR · FR/BR/NFR · WP]
    DES[Audit · ADR · contracts · design]
    BA --> REQ
    REQ --> A
    A --> DES
  end

  subgraph Code[Code repository]
    D[Developer harness]
    SRC[Source · tests · MR evidence]
    D --> SRC
  end

  DES -->|validated handoff| D
  SRC -->|quality handoff| Q[Quality Harness]
  Q -->|findings and evidence| Canon

What each role may change

Business Analyst

May change product intent and requirement state through BA skills and canonical transactions. Does not choose components, libraries, or implementation.

Start with new product, feature, amendment, bug, and WP workflows.

Architect

May accept or return BA intake, record human-chosen decisions, write contracts and budgets, and produce a design package. Does not repair unclear requirements or write product code.

Start with intake, coverage, decisions, and Developer handoff.

Developer

May change the code repository only after accepting the Architect package and receiving plan approval. Does not hand-edit requirements or accepted ADRs; it requests a deviation.

Start with two-repository setup, planning, implementation, and evidence.

Quality

Reads configured local review context and Developer evidence, then persists findings. Applying the result to Jira requires a separate approved action. The private Quality Platform is a distinct planned product for histories within multiple projects and cross-project oversight.

Start with Quality Harness review and Platform direction.

A solo founder still changes hats

One person may work through several roles. Run separate sessions and finish each handoff before changing roles. This preserves the same decision boundaries a team uses.