An enterprise-grade project template for building AI-native products grounded in singularity principles.
Product Harness gives teams a structured, AI-assisted path from a raw enterprise opportunity to a governed, auditable, production-ready product. It extends the AI-native build methodology with three enterprise-specific layers: exponential framing, change management, and policy-governed runtime.
Most enterprise AI projects fail not because the technology is wrong, but because:
- The problem was framed as a 10% improvement when a 10x redesign was possible
- The governance story was bolted on after the build, not designed in from the start
- The organizational antibodies — compliance, security, middle management — were never accounted for
- The AI runtime had no clear boundary from the authoring and configuration tooling
Product Harness makes all four of these explicit before a single line of code is written.
| Principle | Where it lives in this template |
|---|---|
| Massive Transformative Purpose (MTP) | docs/wiki/singularity/06-MOONSHOT-CANVAS.md |
| ExO attributes (SCALE + IDEAS) | docs/wiki/singularity/05-EXPONENTIAL-FRAMEWORK.md |
| 6 Ds of Exponentials | docs/wiki/singularity/05-EXPONENTIAL-FRAMEWORK.md |
| Technology convergence mapping | docs/wiki/singularity/07-TECHNOLOGY-CONVERGENCE.md |
| 10x moonshot framing | docs/wiki/singularity/06-MOONSHOT-CANVAS.md |
| Enterprise change management | docs/wiki/enterprise/08-CHANGE-MANAGEMENT.md |
| Policy-governed AI runtime | docs/wiki/enterprise/09-GOVERNANCE-MODEL.md |
product_harness/
│
├── CLAUDE.md AI assistant operating context
│
├── docs/
│ ├── CLAUDE.md Docs operating rules
│ ├── log.md Append-only operational log
│ ├── delivery-plan-phase-0.md Phase 0 issue graph and milestones
│ ├── execution-protocol-phase-0.md Governed issue execution protocol
│ │
│ ├── sources/ Raw truth — append-only
│ │ ├── decisions/ Product thesis, scope, tech stack,
│ │ │ enterprise context, exponential opportunity
│ │ ├── research/ User problem maps, competitor scans,
│ │ │ technology horizon scans
│ │ ├── transcripts/ Stakeholder interviews and meeting notes
│ │ └── external/ Market reports, regulatory references
│ │
│ ├── wiki/ Synthesized architecture and product narrative
│ │ ├── overview/ 01 - Executive overview and MTP
│ │ ├── architecture/ 02 - System architecture
│ │ │ 03 - Data and state
│ │ │ 04 - Delivery model
│ │ ├── singularity/ 05 - Exponential framework (ExO + 6Ds)
│ │ │ 06 - Moonshot canvas
│ │ │ 07 - Technology convergence
│ │ ├── enterprise/ 08 - Change management
│ │ │ 09 - Governance model
│ │ └── reference/ 10 - Tech stack and constraints
│ │
│ └── spec/ Just-in-time build briefs
│ ├── backend/
│ ├── frontend/
│ ├── runtime/
│ └── enterprise/ Governance gates and audit specs
│
├── apps/
│ ├── frontend/ Operator console or authoring UI
│ └── backend/ Orchestration API and policy engine
│
└── libs/
└── runtime-core/ Governed agent execution kernel
sources/ → wiki/ → spec/ → code
(raw) (synthesized) (brief) (implementation)
| Layer | Purpose | Rule |
|---|---|---|
sources/ |
Raw decisions and research | Append-only, never rewritten |
wiki/ |
Synthesized architecture and narrative | Derived from sources, not invented |
spec/ |
Just-in-time build contracts | Generated before implementation, regenerated on design change |
code |
Implementation | Must not diverge from spec without a wiki update |
Start with these files (rename YYYY-MM-DD to today's date):
docs/sources/decisions/YYYY-MM-DD-enterprise-context.md
docs/sources/decisions/YYYY-MM-DD-exponential-opportunity.md
docs/sources/decisions/YYYY-MM-DD-product-thesis.md
docs/sources/decisions/YYYY-MM-DD-scope-and-nongoals.md
docs/sources/decisions/YYYY-MM-DD-initial-tech-stack.md
docs/sources/research/YYYY-MM-DD-user-problem-map.md
These are working notes. Write them rough. They are raw truth, not launch copy.
Before designing anything, validate your framing:
Read docs/wiki/singularity/05-EXPONENTIAL-FRAMEWORK.md and 06-MOONSHOT-CANVAS.md.
Evaluate the product against:
- Each of the 6 Ds (which stage is this in?)
- Each ExO attribute (which ones apply?)
- The moonshot three-element check (massive problem + breakthrough tech + radical solution)
- The anti-moonshot checklist
Flag any area where the product is thinking in 10% increments instead of 10x.
If fewer than three 6 Ds are at Early or above, stop and rethink the framing.
Read docs/sources/.
Generate these wiki files:
- docs/wiki/overview/01-EXECUTIVE-OVERVIEW.md
- docs/wiki/architecture/02-SYSTEM-ARCHITECTURE.md
- docs/wiki/architecture/03-DATA-AND-STATE.md
- docs/wiki/architecture/04-DELIVERY-MODEL.md
- docs/wiki/singularity/05-EXPONENTIAL-FRAMEWORK.md
- docs/wiki/singularity/06-MOONSHOT-CANVAS.md
- docs/wiki/singularity/07-TECHNOLOGY-CONVERGENCE.md
- docs/wiki/enterprise/08-CHANGE-MANAGEMENT.md
- docs/wiki/enterprise/09-GOVERNANCE-MODEL.md
- docs/wiki/reference/10-TECH-STACK.md
Rules:
- Synthesize from sources only. Do not invent requirements.
- Mark assumptions clearly.
- Keep current implementation truth separate from future phases.
- Cite the source notes for non-obvious claims.
Read the full wiki.
Fill docs/delivery-plan-phase-0.md with:
- 3 to 5 milestones
- 20 to 40 issues total
- Explicit HITL gate issues (not just acceptance criteria — real issues)
- Dependencies and acceptance criteria
- One exponential audit gate after M3
Bias toward a fast end-to-end governed loop, not exhaustive feature coverage.
Drive issues one at a time using docs/execution-protocol-phase-0.md.
The enterprise protocol adds a governance gate check step between implementation and review. Every issue that touches a governance gate must produce a decision record before the reviewer agent runs.
The governance model in docs/wiki/enterprise/09-GOVERNANCE-MODEL.md defines:
| Verdict | Meaning |
|---|---|
ALLOW |
Tool call proceeds without restriction |
DENY |
Tool call is blocked by policy |
ESCALATE |
Tool call pauses for human review |
AUDIT-ONLY |
Tool call proceeds; flagged for post-hoc review |
Mandatory HITL gates — these must appear as explicit issues in the delivery plan and cannot be merged without a decision record:
- Policy approval gate (before first production policy activates)
- Schema lock gate (before downstream systems depend on the contract)
- High-risk action gate (before any ESCALATE verdict triggers a real action)
- Export or publish gate (before any data leaves the enterprise boundary)
Skip any layer and the repo becomes harder to scale with AI assistance:
| Layer | File | Rule |
|---|---|---|
| Raw truth | sources/ |
Append-only |
| Synthesized narrative | wiki/ |
From sources, not invented |
| Build briefs | spec/ |
Generated before each implementation |
| Delivery graph | delivery-plan-phase-0.md |
Issues with acceptance criteria |
| Execution units | GitHub issues | One issue = one PR = one worktree |
| Execution protocol | execution-protocol-phase-0.md |
Governs each issue to reviewed and mergeable |
| System memory | docs/log.md |
Append-only event log |
Adapt early if:
- Your enterprise shape is not
frontend / backend / runtime-core - Your regulated industry (finance, health, defense) needs additional evidence layers
- Your technology convergence profile is hardware-, mobile-, or data-heavy
- You are not using GitHub issues
Preserve the layer boundaries even when you change the folder names.
Contributions and issues welcome. Please open a GitHub issue before submitting a pull request so the change can be scoped against the wiki.
All contributions must be accompanied by the relevant wiki citation or a new source note explaining the rationale.
MIT — see LICENSE for details.