Entities

Milestone

The reviewable checkpoint that gates contract effects — definition, behaviour, operations, and lifecycle on one page.

Entity

A Milestone is a contract-scoped checkpoint: a stateful gate that, once accepted, can trigger an allowed contract effect. It never exists on its own — every Milestone belongs to exactly one Contract and inherits that contract's rules. In the current release a Milestone is accepted by an authorized person, with evidence supporting that decision.

How It Works

A Milestone moves through a two-state lifecycle: PENDING until an authorized human accepts it, then REACHED, at which point its effects may execute according to what the parent contract type allows. Milestones operate inside an ACTIVE contract and never move the contract's own lifecycle.

The indicator on a Milestone is human-readable text describing what a person should verify, and acceptance is an explicit manual act supported by evidence. The standard defines two conceptual trigger families — human attestation and oracle — but only the human-attested path is active; the Oracle family is retained as forward-compatible vocabulary for external or system-provided evidence and possible future automated triggers.

Reaching a Milestone can unlock contract effects, bounded by the parent contract type. A Scoped-on-Demand Purchase requires milestones and allows MOVE_CASH; Revenue Split variants allow CHANGE_PARAMETERS only; Investment allows MOVE_CASH, CHANGE_PARAMETERS, and MOVE_EQUITY. A Milestone may carry several effect entries, and its effects apply prospectively, never retroactively. A JOINT_VENTURE Revenue Split milestone never modifies the JV cap table in the current release.

Statements

These statements fix what a Milestone is and how it gates contract behaviour.

  • A Milestone is a reviewable checkpoint.
  • A Milestone belongs to a Contract.
  • A Milestone has a state.
  • A Milestone has a trigger family.
  • A Milestone can have an effect.
  • Human attestation is the active trigger family.
  • Oracle trigger is the forward-compatible trigger family.
  • Milestone acceptance uses an authorized human act.
  • Milestone evidence supports the acceptance decision.

Operations

Milestone operations sit inside an ACTIVE contract: they accept the gate and apply the contract effects that the parent contract type allows once the gate is REACHED. Acceptance never moves the contract's own lifecycle.

Contracts bind real money and ownership, so the way effects fire has to be disciplined. Milestone acceptance gates rather than skips state changes, and Revenue Split and Investment effects follow the rule the parent contract was signed under rather than an ad hoc edit.

Accept Milestone moves a Milestone from PENDING to REACHED through an authorized human act supported by evidence. It operates inside an ACTIVE contract and does not move the contract's own lifecycle. Once the gating Milestone is REACHED, the contract's economic effects are applied per type: Apply Revenue Split routes value by the Revenue Split rule, and Apply Investment Effect changes investment or ownership economics.

Accept Milestone

  • Accept Milestone moves a Milestone to Reached.
  • Milestone acceptance is an authorized human act supported by evidence.
  • Milestone acceptance operates inside an ACTIVE contract.
  • Milestone acceptance does not move the parent contract's lifecycle.

Apply Revenue Split

  • Apply Revenue Split routes value by the Revenue Split rule.

Apply Investment Effect

  • Apply Investment Effect changes investment or ownership economics.

Lifecycle

The state set is exactly PENDING and REACHED, and the only transition is PENDING to REACHED. While PENDING the Milestone is a text-driven attestation target; it becomes REACHED only when an authorized human accepts it. Execution mode is manual approval only — indicators are plain human-readable text, and the oracle trigger family exists conceptually but is not part of the active path.

Milestones are how a contract gates real effects — moving cash, changing parameters, or moving equity — on an agreed checkpoint actually being met. Because acceptance is a deliberate human act tied to evidence, the moment a milestone flips to REACHED is auditable and the effects it unlocks can be trusted.

Reaching a milestone can unlock effects, but those effects are bounded by the parent contract type: a Scoped-on-Demand Purchase requires milestones and allows MOVE_CASH; Revenue Split variants allow CHANGE_PARAMETERS only; Investment allows MOVE_CASH, CHANGE_PARAMETERS, and MOVE_EQUITY. A milestone may carry several effect entries and its effects apply prospectively, never retroactively.

Just as important is what reaching does not do: it does not drive contract lifecycle transitions, does not create contract-nodes, is not a generic payment-routing primitive, does not allocate initial equity at contract creation, and a JOINT_VENTURE Revenue Split milestone never modifies the JV cap table in the current release. The milestone lifecycle sits nested inside the contract lifecycle rather than as a peer of it.

  • A Milestone lifecycle includes Pending and Reached.
  • A Pending Milestone can become Reached.
  • A Reached Milestone carries acceptance evidence.
  • A Milestone remains Pending until it is accepted as Reached.
  • Milestone acceptance is a milestone transition inside the parent Contract's operating context.

Why It Matters

Milestones are how the standard makes contract behaviour conditional. Instead of effects firing automatically, a Milestone holds them behind a reviewable gate — releasing cash, changing parameters, or reallocating equity only once someone has attested that the condition is met. This keeps agreements auditable and keeps the contract lifecycle separate from the question of whether work was actually delivered.