Glossary

An AI assistant that operates inside a developer environment, reads the local repository as context, and can create and modify files, run commands, and execute multi-step work. ProductHarness is tool-agnostic: it works with whichever agent your org has approved.

The core loop. Build a working prototype in the same session you're thinking through the problem. Validate it with stakeholders reacting to real behavior. Derive requirements, acceptance criteria, and test cases from what was proven — not from what was hoped.

The structural difference between what stakeholders see in a demo and what engineering actually builds. Closed by anchoring prototypes to production conventions, so what was validated is what gets built.

An IDE or CLI tool with an AI coding agent present — the place where the agent lives and operates on the repo as its primary context. In ProductHarness, every role works here, including PMs. Working anywhere else means the agent sees fragments instead of the whole.

The complete lifecycle model: two self-contained loops connected at a crossing point. The Discovery loop runs Signal → Problem Definition → Solution Design → Designs → Prototype → Validation → Acceptance Criteria; the Delivery loop runs Implementation → Automated Verification → E2E/AC Execution → Deploy → Observability → Impact. Each loop cycles independently — Discovery hands off to Delivery at acceptance criteria, and Delivery feeds back to Discovery at impact. Most orgs collapse the two and jump from ideas straight to specs, skipping the prototype-and-validate arc where the framework lives.

Where shipped or abandoned features move out of the active working set, organized by period. Keeps docs/work/ small as features accumulate; nothing is lost, since git history is the deep archive. A feature is archived at the Delivery Impact node.

One directory holding a single feature's entire Double Loop trail — problem framing, discovery, requirements, decisions, handoff, prototypes. Makes "everything about this feature" a path rather than a search, and lets a shipped feature be archived as one move.

The structured repository that holds product work inside the org's standards while it's being built — the way a test harness holds code steady while it's exercised. "The harness" refers to the repo plus the practices that govern it.

Front-matter on every work file — status: active | shipped | abandoned, plus feature, artifact, and updated. Drives the working-set/archive split and lets the agent select only active context.

A connector that lets the agent act on an external system — the backlog, the wiki, a design tool, test management. Each org approves its own allowlist; the harness configures only approved connectors, with credentials kept out of version control.

The property that makes a prototype worth keeping: it follows the org's actual component library, API patterns, and conventions, because those standards were in the agent's context when it was generated. The opposite of throwaway.

Two distinct repos. The org harness repo is generated once from the ProductHarness Specification, inside the org's source control, and holds the org's encoded standards. Each initiative then gets a project repo that pulls the harness from it — so standards stay current across projects with a single source.

The governing principle that requirements, designs, decisions, and test criteria live as version-controlled files in the repo. Backlogs, wikis, and trackers receive from the repo — they don't define it. This is what makes the work auditable and AI-navigable.

The plain-text document from which an org's agent generates its harness repo. It is the delivery mechanism: a client's harness is generated from the Specification inside their own source control — no repository, package, or binary is delivered into a client's environment. (The public template and worked-example repos are illustrative references, not the delivered artifact.) Versioned, human-reviewable, and executable by any approved agent.

How much of the harness is active, matched to the stage of thinking. Starting Out: exploring, full steering infrastructure, no production ties. Production Connection: work headed to engineering, anchored to the production codebase's patterns. Full Integration: validated components sync toward production branches — which requires engineering buy-in, not just tooling.

The files that encode the org's standards and process for the agent: technical standards (API, auth, database, security, testing), node definitions, and work product templates. The agent reads them before generating anything — they're how the org's decisions steer every output.

Prototypes run on made-up data, full stop. Customer data and production data never enter the harness repo. One of the framework's hard security rules, encoded where the agent reads it.

The overhead of humans converting context from one form to another at every handoff — requirements into stories, stories into test cases, intent into tickets. It compounds with scale, falls mostly on the PM, and is the first thing the framework removes.

The features currently in flight — what lives in docs/work/. Kept deliberately small: the moment a feature ships or is killed it moves to the archive (docs/_shipped/). This is how a single repo stays navigable after many features, and how the agent selects context by path instead of reading everything.