The Product Constitution: Rules That Outlive a Single Spec

A team shipped a feature that logged passwords in plaintext. The spec wasn't wrong — it was silent. Three specs earlier, someone had hand-written "never log credentials." The fourth author forgot. The agent did exactly what the spec asked, and the audit found it in production.

The fix isn't a better memory. It's a rule that lives in one place and rides along on every handoff. That's the Constitution.

The retyped-constraint problem

Most constraints belong to one feature. "No double-charge on retry" lives on the payment spec and dies with it — and that's correct. You learn how to write those in The 8-Part IntentSpec and The Anatomy of an Agent-Ready Spec.

But some rules are true for every feature: never log credentials, store timestamps in UTC, match the existing design system, route user-facing strings through i18n. Retyping those into each spec is how they drift — and how the fourth author forgets one.

The tradeoff is real, so name it up front: a Constitution is a layer of governance you have to maintain, and every rule you add narrows what an agent may propose. Over-stuff it and you've replaced judgment with bureaucracy. The payoff is the thing the opening incident lacked — a rule that can't silently go missing.

What a Constitution rule actually is

A rule is not a one-liner. It's a structured object with five parts:

• Text — the rule itself, written as an imperative.
• Rationale — the why. Agents follow rules they understand.
• Scope — where it applies ("API endpoints", "all user-facing text").
• Enforcement — how hard it bites (next section).
• Examples — a do/don't pair that makes the rule unambiguous: for you as you write it, and for Pathmode's AI when it drafts or reviews a spec against the rule.

The rationale and scope aren't decoration: on the context files Pathmode generates, they ride along with the rule so an agent can apply it to a situation you didn't foresee — a bare assertion can't. Here's the line Pathmode writes into your CLAUDE.md and .cursorrules, and the same string the workspace's "How agents see this" preview shows you:

[REQUIRED · constraint] All dates are stored in UTC (scope: API; why: timezone bugs in reporting)

A rule carries reusable judgment — the why — not just more context. Context isn't judgment.

Three categories, three jobs

• Constraint — a hard boundary. "Never log credentials."
• Pattern — a preferred approach, not a hard requirement. "Prefer server components unless you need client state." (This is why patterns default to advisory.)
• Standard — a convention every artifact conforms to. "Timestamps in UTC. Currency in minor units."

The category is a label the agent reads. It doesn't set the teeth — enforcement does.

Enforcement: advisory, required, blocking

This is where a rule gets its bite:

• Advisory — a note to weigh. The agent should consider it.
• Required — must comply. This is the default when you don't choose.
• Blocking — a violation should fail the artifact.

The consequence is concrete. Blocking rules ship with a banner in the exported CLAUDE.md and .cursorrules files — "BLOCKING rules fail the build on violation" — and at review, the spec gate treats a conflict with a Constitution rule as almost always a blocker.

How rules reach the agent: the merge at handoff

Here's the mechanic that makes the primitive earn its keep. When Pathmode hands a spec to an agent, the constraints it sends are your spec's constraints plus the workspace's active Constitution rules, merged into one list under a single heading the agent reads:

## Constraints & Constitution
- [!] No double-charge on retry          ← from this spec
- [!] [BLOCKING] Never log credentials   ← from the Constitution

The author of any given spec never types the Constitution rules — every active rule is injected at handoff. The blocking/advisory marker always travels, so the agent can tell a hard gate from advice; on the exported context files (CLAUDE.md, .cursorrules) the rule's scope and rationale ride along too. The workspace's Governance preview shows you exactly what ships, and only active rules do.

And it isn't only the prompt. The readiness gate's constraint-coverage check counts your Constitution rules too — so a workspace rule helps a thin spec clear the gate, and a blocking rule has teeth at review, not just at runtime. The Constitution is gate-visible, not prompt-only.

That's the proof of the opening fix: the rule can't be forgotten, because no human retypes it.

When a constraint should graduate into a rule

This is the decision no other guide covers. A per-spec constraint should graduate to the Constitution when:

• It's true beyond this one feature.
• Violating it would stop a release regardless of what's shipping.
• You've now written the same line into a second spec.

Three yeses, and it belongs in the Constitution. If instead it's specific to one feature's mechanics — "no double-charge on retry" is a property of the payment flow, not the workspace — keep it local.

Demotion is part of the discipline too. A rule that never actually applies is dead governance the agent still reads on every handoff. Mark it inactive rather than leaving it to dilute the ones that matter.

Start small

A first Constitution is three to five rules, not thirty: one security boundary, your stack's one non-obvious convention, and one voice or brand standard. The free plan caps you at a few rules — treat it as a forcing function to pick the ones that matter, not a wall.

Write each rule, then read it back in the "How agents see this" preview before it rides every handoff. If the rendered line wouldn't change what an agent builds, the rule isn't carrying its weight yet — give it a sharper rationale or a real example.

Open Constitution in your workspace (Sidebar → Constitution) and write your first three rules. Then export any spec and read its "Constraints & Constitution" section: those rules are on the handoff now, and you never typed them into the spec.

Open Pathmode →