The method
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.
01
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.
Captures the request, reviews scope and acceptance, and creates the initial canonical work package. Explore BA.
Opens that package in the shared product repository, adds technical decisions for the selected scope, and preserves its canonical ID. Explore Architect.
Inspects the prepared package and local repository context, implements bounded scope, and records what was checked or skipped. Explore Developer.
Reviews that particular work result, previews application, and applies an approved outcome where configured. Read the role guide.
The Quality Platform is a separate private product direction: retain quality history for each project and support oversight across multiple projects.
02
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.
03
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.
04
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.
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.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.Business Analyst · Architect
canon/
├── vision.md
├── epics/E1-example/
│ ├── index.md
│ ├── E1-FR1.md
│ └── E1-NFR1.md
├── cr/CR-001.md
├── br/<rule-id>.md
└── wp/<WP>/
├── index.md
└── handoffs/ba-architect.handoff.jsonA configurable canon root in the shared product repository. BA records scope and the initial work package; Architect adds technical designs under the agreed design root.
Configured Runtime workflow
checkout/ ├── .project ├── design/<WP>/ │ ├── change-spec.json │ ├── architect-developer.handoff.json │ ├── dev/ │ │ ├── completion-evidence.json │ │ ├── quality-handoff.json │ │ └── git-delivery.json │ └── qa/ │ ├── quality-review.json │ ├── quality-apply-preview.json │ └── quality-apply.json └── work-packages/<WP>/manifest.json
Files accumulate as operations run in the selected checkout. .project is a YAML configuration file. A technical package must be prepared in the repository Runtime will use.
Examples of project artifacts, not an installation scaffold. Paths and repository boundaries depend on the selected workflow. Local .praxis-* journals hold operational state and are excluded from delivery staging. The broader Developer source workflow can also create design/<WP>/dev/plan.md; it is not an output of every Runtime operation.
05
Supported write workflows separate a proposed change from approved application.
Requirements, design inputs and implementation records have named artifacts the next role can open.
Evidence identifies checks run, failed or skipped for that operation. A green label alone does not imply every possible check ran.
Canonical writes, Quality application and Git delivery have distinct decisions. A published change still awaits human review and merge.
06
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.
Book a walkthrough against a real project, or start with the published Developer guide.