Meridian: the harness, inhabited

Not an engineer? This page gets technical on purpose — the detail is the proof it's real. For the same example in plain language, with no file trees, read In Plain Terms →

The ProductHarness template gives you the right folders and a prompt in each file. That's the correct starting point — but on its own it can feel like an empty house. You can see where the kitchen goes; you can't see anyone cooking. The hard part isn't the directory layout. It's knowing what a real steering standard says, what an acceptance criterion authored from a validated prototype actually looks like, and how a single product decision travels from a support ticket to a production component without a translation tax.

So this is the same repository, inhabited. A fictitious company — Meridian — has filled in its standards with real engineering decisions, run one feature through discovery and delivery, and grown the repo across all three adoption stages. Nothing here is a placeholder. It's the artifact you'd point a new PM, designer, or engineer at and say: this is how we work.

The template answers "what goes where." The worked example answers "what does good look like." You need both — but only the second one teaches the framework.

Meridian is a fictitious B2B SaaS company building spend & expense management for mid-market organizations. The team you're looking at is its Product group. Because ProductHarness only matters against a concrete stack, the example commits to one — and every steering standard reflects it, so generated work comes out in Meridian's conventions, not generic AI defaults.

That stack isn't decoration. Here's a slice of what steering/standards/database.md actually encodes — the kind of decision the agent reads before it writes a single line of data code:

- Money: monetary amounts are stored as integer minor units (cents) with a
  separate ISO-4217 currency column. Never floats for money.
- Migrations: Prisma Migrate, backward-compatible (expand/contract). No
  destructive migration ships in the same release as the code that stops
  using the column.
- Naming: tables plural snake_case; PK id (UUID v7); FK {singular}_id;
  created_at / updated_at on every table.

The heart of the example. A single feature — automatically matching uploaded receipts to card transactions — is walked through the entire Double Loop, so you can read the evidence trail from the first signal to a production-shaped component. Each step below is a real file in the repo.

Two artifacts from that trail, side by side — an acceptance criterion, and the production component built to satisfy it:

Given a receipt whose OCR'd amount/currency match the org currency,
  and exactly one candidate transaction scores >= the org threshold,
when the matcher runs,
then the receipt is auto-matched and shown in "Matched" with a one-line
  explanation (merchant, amount, date).

const canMatch = useHasScope('receipt:match');   // scope, not role
// ...
<ConfidenceBadge value={match.confidence} />     // AC1
<p>{match.explanation}</p>
<Button onClick={onConfirm} disabled={!canMatch}>Confirm</Button>

Read top to bottom, the feature is its own argument for the framework: a decision that began as a support ticket arrives in production carrying its full reasoning — and a human signed off at every crossing.

Because moving between stages is additive and non-destructive, the example shows all three as a branch progression. You can git diff between them to see exactly what each stage introduces — nothing is removed, only added.

Even the sync pipeline honors the first principle: it opens a merge request; it never merges to production on its own. Accountability stays with people, all the way to the last step.

The example is a Git repository — the same thing you'd clone and adapt. It pairs with the unopinionated template repo: start from the template when you want a blank harness to fill with your own standards; read the Meridian example when you want to see what "filled in" should look like first.

Browse the worked example on GitLab: productharness-meridian-example →

Its three adoption stages — Starting Out, Production Connection, and Full Integration — live on separate branches, so you can compare them and see exactly what each stage adds.

The reference repositories are public — browse or clone them freely. A training engagement is about installing and adapting the framework for your organization, not about access. Engagements →