---
title: "How it works — Praxis"
route: "/platform"
template: platform-overview
intent: "Explain how independent open harnesses become a connected delivery method."
primaryCta: { label: "Explore the harnesses", href: "#harnesses" }
description: "Four role harnesses connect through artifacts, local Runtime and shared Core contracts. A separate private Quality Platform is planned for project histories."
schemaType: WebPage
hero:
  eyebrow: "The method"
  headline: "Four role harnesses. One connected delivery method."
  sub: "Business Analyst, Architect, Developer, and Quality Harness connect through named artifacts and reviewable decisions. A separate private Quality Platform is planned for quality history across projects."
  primaryCta: { label: "Explore the harnesses", href: "#harnesses" }
  secondaryCta: { label: "Read the docs", href: "/docs" }
sections:
  - { id: independent-value, kind: cards, heading: "Business Analyst → Architect → Developer → Quality Harness" }
  - { id: connected-value, kind: explanation, heading: "A shared method, specialized role tools" }
  - { id: chain, kind: chain, heading: "Every hand-off is an artifact" }
  - { id: handoffs, kind: repos, heading: "Where the work lives" }
  - { id: repositories, kind: cards, heading: "Engineered for trust" }
  - { id: quality-boundary, kind: quality, heading: "Private Quality Platform · planned" }
  - { id: next-step, kind: cta, heading: "See it on your codebase" }
---

## Business Analyst → Architect → Developer → Quality Harness

Each person can use the harness for their own responsibility. Compatible artifacts and shared working rules let those roles continue the same piece of work. Core defines shared contracts; Runtime supplies local tools; role harnesses guide the person through their part. Each person uses the tools for their responsibility while the team shares the same artifact contracts.

- **Business Analyst** captures the request, reviews scope and acceptance, and creates the initial canonical work package. [Explore BA](/platform/ba).
- **Architect** opens that package in the shared product repository, adds technical decisions for the selected scope, and preserves its canonical ID. [Explore Architect](/platform/architect).
- **Developer** inspects the prepared package and local repository context, implements bounded scope, and records what was checked or skipped. [Explore Developer](/platform/developer).
- **Quality Harness** reviews that particular work result, previews application, and applies an approved outcome where configured. [Read the role guide](/docs/plugins/quality).

The [Quality Platform](/platform/quality) is a separate private product direction: retain quality history for each project and support oversight across multiple projects.

## A shared method, specialized role tools

Research, alternatives, planning, work, and verification give the team a useful discipline. Installed tools and required checkpoints differ by role and operation. Review a proposed canonical write, Quality application, or Git delivery at the point that action requires approval. Evidence should show skipped checks as well as completed checks; a verdict is specific to its operation.

## Every hand-off is an artifact

The connection is a set of inspectable artifacts, with review and rework possible at each boundary:

**request → accepted scope and initial WP → technical enrichment → bounded implementation and evidence → Quality Harness review → separately approved delivery**

The BA creates the initial canonical work package. Architect enriches that same package with decisions relevant to the selected scope. Developer checks the handoff and its referenced files before changing code. Quality Harness reviews the result. Applying its outcome and publishing with Git each have separate approval boundaries. Current Runtime execution packages use a separate local identity, which needs an explicit mapping to the canonical package when both workflows are used.

## Where the work lives

The illustrated team setup uses a shared product repository for BA and Architect, and a code repository for Developer. Repository topology is a choice; moving the prepared package between them is an explicit preparation step.

- **Product repository · filesystem canon example** — BA and Architect share a checkout. The canon holds vision, epics, requirements, changes, business rules and the initial `wp/<id>/`; Architect adds technical artifacts under the agreed `design/` root. Architect enriches the BA-created WP under the same ID. This is a source-tool example, not a universal scaffold.
- **Code repository · local Runtime example** — the selected `repo` is the code and test root. Runtime looks for prepared design and manifest inputs there and writes local operation artifacts there. Ignored local journals are not automatically committed canon. Runtime does not automatically import from a sibling product checkout.

## Engineered for trust

- **Review a change before applying it.** Supported write workflows separate a proposed change from approved application.
- **Keep the handoff inspectable.** Requirements, design inputs and implementation records have named artifacts the next role can open.
- **See what was checked.** Evidence identifies checks run, failed or skipped for that operation. A green label alone does not imply every possible check ran.
- **Keep ownership clear.** Canonical writes, Quality application and Git delivery have distinct decisions. A published change still awaits human review and merge.

## Private Quality Platform · planned

Quality Harness can review one work result now. The private Quality Platform is planned to keep repeated quality observations within each project and an overview across projects. We are building project history and recurring evaluation into the Platform. Talk with us about access and integration for your team.

## See it on your codebase

Book a walkthrough against a real project, or start with the published Developer guide.