---
title: "Praxis for Engineering Directors"
route: "/for/engineering-director"
template: role
intent: "Turn individual AI agent speed into a shared delivery framework for the team."
parent: "/for"
primaryCta: { label: "Map one delivery flow", href: "/enterprise#contact" }
description: "The constraint on delivery was never typing speed — it is what happens between people. Praxis connects specialized role harnesses through reviewable artifacts, with distinct approvals for canonical writes, Quality application and Git delivery."
schemaType: WebPage
personaAngle: "Pain → why → solution → case → proof: predictable, accurate and traceable delivery from a rebuilt pipeline"
hero:
  eyebrow: "For Engineering Director"
  headline: "Your engineers generate more code. You still carry the coordination cost."
  sub: "Praxis turns individual AI speed into one shared delivery process: versioned hand-offs in git, human gates, and evidence linked to each requirement. What ships can be checked against what was asked."
  primaryCta: { label: "Map one delivery flow", href: "/enterprise#contact" }
  secondaryCta: { label: "Talk to us", href: "/enterprise#contact" }
sections:
  - { id: pain, kind: pain, heading: "Faster code, unchanged dates" }
  - { id: why-individual-speed-stalls, kind: explanation, heading: "The gap, in the delivery room" }
  - { id: team-framework, kind: explanation, heading: "Why it doesn't fix itself" }
  - { id: team-repositories, kind: flow, heading: "One product record. Clear ownership across the team." }
  - { id: proof, kind: proof, heading: "What changes for your organisation" }
  - { id: next-step, kind: cta, heading: "See the governance model" }
---

## Faster code, unchanged dates

Individual output can rise while review queues, integration work and rework still carry the delivery date. You need a way to see the accepted request, the technical decision and the implementation evidence together when a change reaches review.

## The gap, in the delivery room

Each specialist may have a useful assistant but a different understanding of what is ready. A code patch cannot explain which business rule was accepted or which package version it followed. A handoff that includes the source links and a named owner makes that gap visible before it becomes review churn.

## Why it doesn't fix itself

The team needs shared artifact contracts and explicit ownership. BA and Architect work on the same product record; Developer works in the code checkout; Quality Harness reviews a particular result. Local Runtime is infrastructure in the chosen workspace, not a central team server or an access-control boundary between roles.

## One product record. Clear ownership across the team.

In the illustrated topology, **BA + BA Harness** and **Architect + Architect Harness** share one product repository. BA accepts scope and creates the initial canonical WP; Architect enriches that same ID with technical decisions and a prepared handoff. The team explicitly makes the package and its referenced files available to the code workspace. **Developer + Developer Harness** implement there and record evidence. **Quality Harness** returns findings for review and, where configured, previews application. Git publication follows a separate approval and still awaits human merge.

The repository split is a deployment choice. Current Runtime uses the selected `repo` as its input lookup and code/test root; it does not automatically sync a sibling product checkout. The detailed topology below is also available in [the handoff guide](/docs/guide/handoffs).

## What changes for your organisation

- **Specialized roles, shared contract** — each person uses the harness for their responsibility; the next person opens the named package and checks its links.
- **Visible checks** — evidence shows what ran, failed or was skipped. A Quality finding can return to Developer for rework.
- **Clear approvals** — canonical writes, approved Quality application and Git delivery are distinct. None implies automatic merge.
- **A path to history** — the private Quality Platform is planned to retain observations per project and show an overview across projects. Discuss access and integration separately from the delivered Quality Harness.

### The case

The [Watchlink case](/cases/watchlink) describes a product context where preserving decisions matters. It does not establish deployment of current Runtime or a live Platform dashboard.

### Proof you can open

For a selected WP, inspect the accepted scope, the Architect handoff, the code change, the checks actually run and any Quality findings. These artifacts support investigation; they do not automatically identify the exact cause or owner of every defect.

## See the governance model

Bring one current delivery slice and map its repository ownership, package preparation and approval points with us.