# Organization lifecycle

> An organization is written, checked, founded, and then runs. From that point the definitions change only through amendment, and the machinery changes only through binding. Those are two different paths with two different kinds of authority, and neither requires stopping the other.

Canonical: https://endoskeletal.com/lifecycle/
Last updated: 2026-09-28

**Diagram: Lifecycle: source, check, IR-D, found, operate; runtime acts loop on operate; amendments go propose, decide, materialize back to IR-D.**

Top row, left to right: **Source** (.esk modules) → **Check** (diagnostics E, W, U, I) → **IR-D** (definitions in force) → **Found** (founding declaration) → **Operate** (the log grows).

- Runtime loop on Operate: acts, binds, scaling and failover are validated against the IR-D in force and never compile anything.
- Amendment loop: Operate → **Propose** (epistemic, anyone) → **Decide** (under the amend power; quorum, delay, review) → **Materialize** (Compiler party, attenuated to the approved delta) → new IR-D version, after which bindings are reconciled against the new requirements.

*Two loops. Runtime acts are validated against the IR-D in force and never compile anything. Amendments change the IR-D and are the only thing the compiler materializes.*

## 1. Found

Founding is compilation of the initial specification, approved by the founders' declaration. It appends the founding event (which references a run manifest stating whether this log is real or simulated, and which clock and entropy it uses), the enactment of every definition, and the first appointments. From here every norm has a chain of recognition back to the rule of recognition:

*chain of recognition (static check, Meridian)*

```console
esk:norm/Meridian.Operations.ScaleEnvelope ← founding ← esk:norm/Meridian.Const.Recognition (root)
esk:norm/Meridian.Const.CompilerDelegation ← Meridian.Const.Amend ← founding-declaration ← Meridian.Const.Recognition (root);
    attenuated to the approved delta at felicity
```

## 2. Run

The engine loop is: append an event, recompute the projections it could affect, detach commitments from norms whose conditions became true, mark commitments fulfilled or violated, open or close gaps, fire or-else norms. The clock capability appends ticks; in simulation it's a discrete-event scheduler that jumps to the next thing that's due, so a simulated month costs as many steps as there are deadlines in it, not seconds.

Participants act through the organization's interfaces. Every institutional act is checked for felicity. Every external act must cite the institutional act that authorized it (`authorizedBy`) and the realization it goes through (`via`).

## 3. Rebind without recompiling

Changing which mechanism realizes a requirement is runtime work. A realization moves through states, each change a recorded event:

| State | Reached by | Who can cause it |
| --- | --- | --- |
| proposed | a candidate realization record from research | Architect (epistemic) |
| evidenced | its satisfaction claim reaches T from sandbox evidence | computed from the Architect's evidence |
| staged / shadow | `bind(r, staged)` or `bind(r, shadow)` | a bind-power holder |
| active | one atomic `bind(r, active)` that demotes the old one to fallback | a bind-power holder, only when every required conjunct is T |
| fallback → superseded | exit capability invoked after the rollback window | authorized `execute` events |

There is never an index at which two realizations are active for the same requirement. In the Meridian reference run, 58 binds and 32 cut-overs happened this way over 36 months, including Compute failing back and forth between two regions during outages. None of them changed a line of the specification.

## 4. Amend

Any member may `propose`. The proposal detaches the governance commitments the current definitions require: in Meridian, a Finance impact analysis, then the Owner's decision (collective level) or two Director votes plus a seven-day cooling-off (constitutional). The approval is a `decide` under the amend power. Then the constitution obliges the Compiler party, within a day, to materialize it:

1. Translate the approved source delta into an IR-D delta.
2. Check the whole resulting IR-D.
3. Append `amend` / `enact` events on behalf of the approving persona, each citing the approval.
4. Derive the requirement delta and reconcile existing bindings: unchanged stays bound, tightened is re-evaluated, retired is orphaned, new with no candidate is a gap.

The compiler holds no power of its own. If it tries to change anything outside the approved delta, the act misfires. The Meridian scenario injected exactly that fault at month 29; the log recorded:

*amendment log, index 279913*

```console
amend esk:norm/Meridian.OpsSpend   ✗ misfire
  esk:norm/Meridian.Const.CompilerDelegation: delegation not covering: target Meridian.OpsSpend is outside
  the approved delta ['Meridian.Operations.ScaleEnvelope', 'Meridian.Operations.ScaleApproval.Duty'] (attenuation)
```

Commitments already running stay bound to the norm version they detached from. New activations use the new version.

## 5. Simulate at any point

A simulation is the same organization, same IR-D, same engine, run against emulated providers, emulated or replayed participants, a virtual clock and seeded entropy. The substitution happens below the capability boundary, and no norm can read whether it's in a simulation. A simulated log can fork from a checkpoint of a real one, and paired runs with the same seeds differ only where the definitions differ, so you can test an amendment before approving it. Simulated history enters a real log only as evidence cited by a claim.