The VenturePilot constitution, annotated

This is the constitution behind VenturePilot, the AI business-development product I am building with coding agents. It is the document every requirement, architecture decision, prompt and piece of code in the project is subordinate to, and it is published here as it stands, version 1.4, so that the argument in Write the constitution before the code can be checked against the real thing.

Each article has a principle and a violation test: a statement of what a breach would look like, so that a reviewer or an automated check can answer yes or no. My notes, marked as such, say why some articles exist or what they caught during the build. They are not part of the constitution. The supporting documents it governs (requirements, architecture decisions, contracts, the test strategy) are not published. Not every obligation added in the latest versions is implemented yet; the amendment record at the end lists the compliance work each version created, which is the honest way to publish a rule before it is fully met.

Use it. The constitution text, my notes and the template are all free to adapt under a Creative Commons Attribution 4.0 licence: reuse it, change it, credit the source. Two downloads:

• A blank project constitution template (Markdown): the same structure with the product-specific content removed, a governance article ready to fill in, a section for recording where it sits in a tree of constitutions, and notes on writing articles.
• The VenturePilot constitution, version 1.4 (Markdown), without my notes.

---

Preamble

This Constitution defines the architectural and product rules that VenturePilot does not break. It has authority over the System Plan, Software Requirements Specification, architecture decisions, prompts, agent behaviour and implementation.

Where another artefact conflicts with this Constitution, that artefact must be corrected, the Constitution must first be amended under Article 15, or, for an Article that permits it, a recorded exception must be granted under Article 16.

VenturePilot's operating principle is:

Autonomous internally. Permissioned externally.

Each Article includes a violation test so that it can be enforced during design, implementation and review. Violation tests are examples of breaches, not a complete definition: the named checks required by Article 16 must cover every normative requirement of each Article.

Article 0: Product scope and tenancy

Principle: VenturePilot is a multi-tenant opportunity operating system intended to serve paying customers. Authentication, tenant isolation, onboarding readiness and usage accounting are architectural foundations, not later retrofits.

Release sequencing, such as a private beta before paid launch, is decided in the architecture decisions and roadmap. Whatever the sequence, the data model must be billing-ready from the first release.

Violation test: A business record that cannot be unambiguously assigned to one tenant, or a release that allows one tenant to access another tenant's data, is a violation.

Article 1: VenturePilot owns the platform and system of record

Principle: VenturePilot owns its product architecture, business logic, tenant model, permissions, approvals, prompts, audit history and durable memory. A database under VenturePilot's control is the authoritative system of record (currently PostgreSQL; see ADR-003).

AI providers, agent frameworks, browser sessions, caches and temporary runtime memory are execution dependencies, not authoritative stores.

Violation test: Durable product state that exists only inside an AI provider, agent runtime, browser profile, cache or local file is a violation.

Article 2: Replaceable providers and runtimes

Principle: External providers and execution runtimes are replaceable behind stable internal interfaces. This includes AI, embeddings, agent runtimes, email, calendar, browser automation, storage, billing and notification services.

Business modules request capabilities such as opportunity.score or outreach.draft; they do not select provider models.

Violation test: A provider SDK import, provider model identifier or provider-specific response type outside its adapter or gateway boundary is a violation.

Article 3: Modular services without premature distribution

Principle: Distinct capabilities have explicit interfaces, ownership and tests. They may initially be deployed together as a modular monolith. Separate deployment is introduced only where isolation, scaling, reliability or operational evidence justifies it.

Modules do not access another module's private implementation or mutate its state directly.

Violation test: A capability with no defined boundary, or a module that calls another module's private functions or tables in place of its published interface, is a violation. Co-deployment alone is not a violation.

Article 4: Human authority over external actions

Principle: Internal discovery, research, classification, deduplication, scoring and drafting may run autonomously. No external action takes effect without explicit, attributable and logged human approval.

An external action is any communication sent on a tenant's behalf, any submission or application, any commitment, and any change to a third party's records or calendar. Routine infrastructure operations and provider requests, such as AI calls, research queries and storage writes, are not external actions; they run under granted capabilities (Article 6) and the budget and privacy rules (Articles 10 and 11).

Approval applies to a canonical payload: the exact content, the recipient or target, the sending account and the tenant. Any change to the canonical payload, however small, requires fresh approval; transport encoding that does not change what the recipient receives is not a change. Approval credentials are tenant-scoped, single-use, time-bounded and revocable by the approver before execution.

An approval authorises one externally observable effect. Every external action carries an idempotency key. An attempt whose outcome is uncertain, such as a timeout after the request was sent, must not be retried until the outcome has been reconciled or the provider is known to deduplicate on that key. A resend is a new action and needs a new approval.

Violation test: An external action that takes effect without a valid approval record bound to its canonical payload; an approved action that takes effect twice, after revocation or expiry, or against a different recipient, account or tenant; or a retry after an uncertain outcome without reconciliation or provider deduplication, is a severe violation.

Article 5: Multi-tenant isolation by construction

Principle: Every tenant-owned business table carries tenant_id. Database row-level security is enabled and enforced. Application checks supplement RLS but never replace it.

Foreign keys and constraints must prevent records from different tenants being linked. Background jobs, caches, object storage paths, vector searches and runtime contexts are tenant-scoped.

Violation test: A tenant-owned table without tenant_id and an active RLS policy; an unscoped query; a cross-tenant relationship that the database permits; a privileged function that bypasses RLS without verifying the caller's tenant; or a job, cache entry, storage path, vector search or runtime context that can read or write another tenant's data, is a violation.

Article 6: Capability-based security and least privilege

Principle: Users, services, agents and runtime jobs receive explicit, scoped capabilities rather than broad trust. Capabilities are tenant-scoped, purpose-limited, time-bounded where practical and logged.

Untrusted runtimes, including browser automation, do not receive direct database authority or approval authority.

Violation test: A runtime with unrestricted database, filesystem, secret or outbound-action access is a violation. Any capability not explicitly granted is denied.

Article 7: Auditable AI decisions

Principle: Every AI request and stored AI artefact is traceable. The system records the capability requested, relevant input or an approved privacy-preserving representation, prompt/template version, provider, model, timing, token usage, cost, structured output, user-facing rationale, supporting evidence and outcome.

VenturePilot stores decision rationale and evidence; it does not require or depend on private chain-of-thought.

Audit records are themselves personal data where they contain it, and are subject to Article 11: minimised to what traceability requires, access-controlled, and retained and deleted under the same rules. A rationale is an evidence-supported explanation for the user; it is not treated as a faithful account of the model's internal reasoning.

Violation test: A stored AI score, classification or draft that cannot be linked to its tenant, request, model, prompt version, cost, user-facing rationale and supporting evidence, or audit data retained, exposed or shared beyond the rules of Article 11, is a violation.

Article 8: Event-driven workflows

Principle: Significant state transitions are represented by durable events. Asynchronous workflows use an outbox/queue mechanism with idempotency, retries and observable failure handling.

Redelivery of an event that leads to an external action is governed by the single-effect rule in Article 4. Simple request-response queries may be synchronous. Event-driven design must not be used as decoration where a normal module call is clearer.

Violation test: A state change and its required event can be committed independently, or an event consumer cannot safely handle redelivery, is a violation.

Article 9: AI resilience and graceful degradation

Principle: AI capabilities define their own timeout, retry, fallback and degraded-mode policy. The AI Gateway may route to alternate providers where privacy, quality and tenant budget policies allow.

Not every capability needs a rules-engine substitute. Where no safe substitute exists, work is queued for retry or human handling.

Violation test: A provider outage can corrupt workflow state, bypass a budget/privacy rule or cause an unsafe external action is a violation.

Article 10: Per-tenant cost governance

Principle: Every billable AI call records measured or estimated cost. VenturePilot enforces per-tenant budgets, workflow limits and concurrency limits before dispatch. Provider-level spending caps are additional safeguards, not substitutes for tenant controls.

Automatic escalation to a more expensive model must remain within the tenant's policy and budget.

Violation test: An unattended workflow can spend without a tenant ceiling, loop bound or recorded cost is a violation.

Article 11: Security, privacy and data minimisation

Principle: Secrets and personal data are protected by default. Secrets are never committed, logged or stored in plaintext application columns. Personal data is collected for stated product purposes, access-controlled and governed by retention and deletion rules.

External content is untrusted and may contain prompt injection. Content retrieved, received or produced by tools can never grant a capability, approve an action or amend these rules, whatever it says. Model inputs are minimised and classified by sensitivity. Provider routing respects the tenant's privacy policy and applicable contractual obligations.

VenturePilot's controller/processor roles, lawful bases, agreements, retention, data-subject handling and incident duties must be reviewed by qualified legal counsel before general commercial launch.

Violation test: Secret disclosure, purposeless personal-data collection, unnecessary model disclosure, cross-tenant access or following instructions embedded in researched content is a violation.

Article 12: Testing, delivery and observability

Principle: Tests, continuous integration, structured logs, metrics, health checks and traceable workflow identifiers are present from the first release.

Tenant isolation, approval enforcement, idempotency, budget enforcement and provider failure paths require automated tests.

Violation test: A changed service boundary with no relevant tests, a merge path that does not run tests, or a production workflow whose status cannot be determined is a violation.

Article 13: Portable, reproducible deployment

Principle: The always-on application runs on secured infrastructure using containerised, reproducible deployment, and is recoverable from tested backups. Hosting choices are architecture decisions (currently VPS-first application hosting with managed PostgreSQL; see ADR-003 and ADR-004), and can change without amending this Constitution.

Heavy AI inference is consumed through replaceable providers behind the AI Gateway. Self-hosted or local models may be added behind the same gateway when usage, privacy or economics justify them.

The product must not require a particular hosting vendor, cloud platform, AI provider or agent runtime.

Violation test: An undocumented manual server state, irreplaceable vendor dependency, untested backup, publicly exposed database or production dependency on a developer laptop is a violation.

Article 14: Professional reputation and product integrity

Principle: VenturePilot treats each tenant's reputation as a protected asset. It avoids spam, fabricated experience, misleading claims, undisclosed commitments and unjustified confidence.

Standing tenant goals guide discovery, scoring and prioritisation. The system must expose uncertainty and the basis for recommendations.

Violation test: Generated outreach contains an unsupported factual claim, or automation optimises message volume at the expense of relevance and consent, is a violation.

Article 15: Amendment

Principle: This Constitution changes only through a recorded amendment approved by the product owner, identifying the affected Articles, rationale, migration consequences, version increment and effective date. Existing work that the amendment makes non-compliant is listed and brought into compliance as tracked work. The amendment record shows who approved each version, when it took effect and what compliance work it created. An amendment does not retroactively excuse a breach recorded before it took effect. Previous versions remain in version control.

Violation test: A design or implementation silently contradicts an Article; this document changes without an amendment record and version increment; or an amendment takes effect without a recorded approver, effective date and list of resulting compliance work, is a violation.

Article 16: Governance, enforcement and breach response

Principle: The product owner interprets this Constitution, resolves conflicts that an agent or reviewer has stopped on, and approves amendments. A named deputy may act in the product owner's absence for interpretation and breach response, not for amendment.

Every Article has at least one named check (automated test, database policy, CI gate, runtime permission or review package), recorded in docs/019-TEST-STRATEGY-v1.md against the Article number, with an owner. Implementation agents, jobs and runtimes may submit evidence but may not accept their own work or change package or release status. The coordinator (a deterministic program, not an AI agent, that validates submitted evidence against each package's declared checks) and the product owner may change completion or release status only on verified evidence of compliance, or under a valid exception where this Constitution permits one.

On a detected breach of Articles 4, 5, 6, 10 or 11: stop the affected workflow, block release, contain any external effect, record the incident, and re-verify before resuming. Breaches of other Articles block completion of the affected package until resolved or excepted.

Articles 4, 5, 6, 10 and 11 admit no exceptions; they can change only by amendment under Article 15. For other Articles the product owner may grant a narrow, written, expiring exception that names the Article, scope, reason, compensating control and expiry date.

An authorised operator can at any time pause discovery and drafting for a tenant or for all tenants, revoke outstanding approvals, cancel queued external actions and revoke runtime credentials, and the system remains recoverable from that state.

This Constitution is reviewed at each phase gate, before general commercial launch, and after any severe violation.

Violation test: An Article with no named check or owner, an agent or runtime changing its own completion or release status, external work continuing after a detected breach of a no-exception Article, an exception to a no-exception Article, an exception granted by anyone other than the product owner, an exception without an expiry, or the absence of a tested pause-and-revoke path, is a violation.

Amendment record

---

If you are deciding how to govern AI agents or coding agents in your own organisation, and want a second pair of eyes on the rules before the first prompt, that is a conversation I have often.