---
title: "Architect — Praxis"
route: "/platform/architect"
template: platform-component
intent: "Turn accepted requirements into bounded technical decisions."
parent: "/platform"
primaryCta: { label: "Read the Architect guide", href: "/docs/plugins/architect" }
description: "The Architect role turns a work package into decisions, contracts, and NFR budgets a Developer can build from. An early, actively developed part of Praxis."
schemaType: WebPage
hero:
  eyebrow: "Stage"
  headline: "Architect harness: turn requirements into bounded technical decisions."
  sub: "The Architect turns a work package into decisions, contracts, and NFR budgets — a number and a way to check it, not a wish — plus a design package a Developer can build from."
  primaryCta: { label: "Read the Architect guide", href: "/docs/plugins/architect" }
  secondaryCta: { label: "Docs", href: "/docs" }
maturity: preview
sections:
  - { id: pain, kind: pain, heading: "What the Architect does" }
  - { id: input, kind: explanation, heading: "The package the Architect opens" }
  - { id: capabilities, kind: cards, heading: "Capabilities" }
  - { 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 codebase" }
---

## What the Architect does

You inherit accepted business scope and the BA-created canonical work package. The Architect harness helps turn the affected scope into technical decisions, constraints and a bounded Developer input while keeping the package identity and links intact. A design review can reveal missing requirements; it does not silently rewrite accepted business intent.

## The package the Architect opens

In the shared product repository, open the WP, linked requirements, acceptance criteria, business rules and existing decisions. Check what the change actually touches. Record missing inputs and ask for review before filling a gap that changes business scope.

## Capabilities

- **Selected design coverage** — inspect the systems and contracts affected by this package, then record decisions for that scope. This is a reviewable judgment, not an automatic guarantee of total coverage.
- **Alternatives and constraints** — compare material options and state the non-functional constraints that can be checked. A council or deeper review is used when the decision warrants it.
- **Scoped handoff** — prepare `change-spec.json`, `architect-developer.handoff.json`, and `context-slice.md` where the source-tool workflow calls for them; keep referenced files together.
- **Stable identity** — enrich the BA-created canonical WP under the same ID. If Runtime later uses a local execution-package ID, record the mapping explicitly.

## What it hands off

Developer receives a prepared technical package: accepted scope, relevant decisions and contracts, selected context, constraints and missing-input notes. Making this package available in a separate code workspace is an explicit preparation step, not automatic repository synchronization.

## Going deeper

[Architect setup and commands](/docs/plugins/architect) cover the installed path and the source-tool path separately.

## Try it on your codebase

Choose one accepted WP and inspect the affected design before preparing Developer input.