--- title: 'Flagridge platform: four role harnesses, one method' description: 'See how four role harnesses, shared Core contracts and local Runtime tools pass named artifacts and reviewable decisions from Business Analyst to Quality.' url: 'https://flagridge.com/platform' type: 'page' template: 'platform-overview' language: 'en' --- # Four role harnesses. One connected delivery 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. Primary action: [Explore the harnesses](https://flagridge.com/platform#harnesses) ## 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](https://flagridge.com/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](https://flagridge.com/platform/architect). - **Developer** inspects the prepared package and local repository context, implements bounded scope, and records what was checked or skipped. [Explore Developer](https://flagridge.com/platform/developer). - **Quality Harness** reviews that particular work result, previews application, and applies an approved outcome where configured. [Read the role guide](https://flagridge.com/docs/plugins/quality). The [Quality Platform](https://flagridge.com/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//`; 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. ## Related - [Architect harness: from requirements to bounded decisions](https://flagridge.com/platform/architect) — Turn a work package into decisions, contracts and measurable NFR budgets, and prepare a design package a Developer can build from without guessing intent. - [Business Analyst harness: from request to accepted scope](https://flagridge.com/platform/ba) — Turn a change request, feature or bug report into typed, traceable requirements and a work package, with scope approved by a person before anything is written. - [Developer harness: from bounded package to verified change](https://flagridge.com/platform/developer) — Inspect a prepared package, research what the change touches, implement bounded scope and record evidence, including skipped checks, for a reviewer to inspect. - [Quality Harness: review one work result against evidence](https://flagridge.com/platform/quality) — Learn what the Quality Harness does for one work result, from checks to a verdict backed by evidence, and where the planned Quality Platform keeps history. --- HTML: https://flagridge.com/platform Markdown: https://flagridge.com/platform.md