Specification · v1.0

The Perpetual Engine.

A structural standard for AI-native ventures. This document defines the registries, the methodology, the giving substrate, and the adoption criteria. The standard is open. Anyone may adopt it. The reference implementation is Perpetual Core.

Version

v1.0

Status

Published

Conforming impls

1

License

Open · CC BY 4.0

§ 1

Purpose

What the Engine specifies, and why it exists.

The Perpetual Engine is a structural standard for AI-native ventures — a way to build a company so that its operations, methodology, and mission funding are bundled into one substrate.

AI ventures built on the Engine commit to operator-owned data, an open methodology, and a structural giving floor that funds an aligned mission entity. The standard exists so this structure can be adopted by anyone — not as competitive moat for one company.

Imitation is the goal. The reference implementation is the contribution.

§ 2

Registries

Eight registries are the substrate.

Every conforming implementation MUST install the eight registries below as the single source of truth across the venture's operations. Field-level extensions are permitted; the core schemas are reserved.

2.1

Entities

{ id, name, type, jurisdiction, parent_id, audit_ref }
2.2

People

{ id, name, role[], org_id, consent_state, contact[], audit_ref }
2.3

Projects

{ id, name, parent_id, budget, start, end, owner_id, audit_ref }
2.4

Work items

{ id, project_id, type, status, assignee_id, due, audit_ref }
2.5

Knowledge

{ id, source[], embedding_ref, kind, retention, audit_ref }
2.6

Agents

{ id, scope, model, refusal_rules, owner_id, audit_log_id }
2.7

Workflows

{ id, steps[], triggers[], version, owner_id, audit_log_id }
2.8

Events

{ id, actor, action, object, ts, prev_hash, audit_ref }

§ 3

Framework

The Learn → Wire → Automate → Scale arc.

Every AI capability the venture builds — internally or for clients — MUST follow this four-phase arc. Phases MAY overlap; none MAY be skipped.

3.1

Learn.

Operator-grade reading of the host organization. Minimum 2 weeks. No intake forms — sit in the meetings.

3.2

Wire.

Install the 8 registries in the host's storage. Migrate existing data. Minimum 3 weeks.

3.3

Automate.

Build skills against real workflows. SKILL.md format, per-org JSON config. Versioned, auditable.

3.4

Scale.

Hand over operation. Documentation, training, and transfer of ownership to the host's team.

§ 4

Giving

The structural mission floor.

Every conforming implementation MUST commit a minimum 10% of top-line revenue to an aligned 501(c)(3) or equivalent legal entity. Subscriptions and SaaS products MAY carry a higher rate (default 15% for direct-to-consumer products).

Formula

mission_floor =
  Σ (engagement_revenue × 0.10) +
  Σ (saas_revenue × 0.15) +
  Σ (other_product_revenue × 0.10)

destination = aligned_501c3_or_equivalent
disclosure  = annual_audit + per_invoice_line_item

The destination MUST be an independent 501(c)(3) (or equivalent jurisdictional charity) with audited financials. The implementation MUST publish its annual audited contribution figure. Each invoice the implementation issues MUST line-item the mission contribution.

The floor is non-negotiable. Higher rates are encouraged.

§ 5

Adoption

Six criteria for a conforming implementation.

A venture is “Engine-conforming” if it meets all six criteria below. A venture working toward conformance is “Engine-aligned.”

5.1

Registry-first substrate

The 8 registries are installed and operated as the single source of truth across the venture's operations. No critical data lives outside them.

5.2

AI-First Framework discipline

Every AI capability built into the venture follows the Learn → Wire → Automate → Scale arc. No phases skipped.

5.3

SKILL.md skills library

Skills are versioned, auditable units in markdown frontmatter + JSON config. No proprietary opaque skill formats.

5.4

Structural mission floor

10–15% of top-line revenue across every product, engagement, and subscription flows to a 501(c)(3) parent or equivalent legal entity. Audited annually. Line-itemed on every invoice.

5.5

Operator ownership of installs

Engagement-style installs end with documentation, training, and transfer. The host organization owns the system after handover. No vendor lock-in.

5.6

Public disclosure of compliance

Conforming implementations publicly state their conformance level (Engine-aligned / Engine-conforming) and link to their audited reports.

§ 6

Implementations

Conforming implementations.

Ventures that have publicly declared conformance to v1.0. New implementations may be added via email to lorenzo@perpetualcore.com. Future versions of this spec will move registration to a public process.

§ 6.5

Field operations

Reference field operations.

Operating sites where the Engine is run under live regulatory constraint, in production. Distinct from conforming implementations (which are stand-alone ventures): field operations are the operational arms inside an implementation where the methodology is stress-tested.

§ 7 · Adopt

Build the next conforming implementation.

If you're building an AI-native venture and intend to meet the six criteria, email us. We'll add you to the implementations list and compare notes on what works.