Skip to content

Meepo Transition Integrity

Meepo is AncientOS transition integrity infrastructure. Its job is to make sure trusted continuity survives state changes by checking that an approval still matches the exact action, context, posture, output boundary, and scope that is about to move forward.

Meepo is deliberately narrow. It is not orchestration, planning, routing, policy evaluation, generic middleware, or approval orchestration. Callers own lane vocabulary and lifecycle choices. Meepo owns transition packets, revalidation comparison, fail-closed result states, and transition audit artifacts.

TOCTOU

TOCTOU means "time of check to time of use." In governance terms, it is the gap between approving an action and later using that approval to mutate state, publish content, execute a bounded lane, or promote memory.

The risk is simple: the approved packet may no longer describe the current world. The target may have changed, policy may have changed, runtime posture may have changed, rollback may no longer be valid, or the expected output may leave the approved boundary.

Why One Gate Is Insufficient

A single approval gate proves that a human approved something at one moment. It does not prove that the same thing is still being executed later.

Approval is not a blank cheque. Approval applies only to a specific action, target, context, policy, expected mutation, rollback plan, validation plan, output boundary, runtime posture, and authority state. Meepo revalidates those fields at transition checkpoints and fails closed when drift is detected.

The continuity question is: can trust from the approved state be carried into the next state? If assumptions drifted, context no longer matches, approval is stale, output bounds changed, or execution would leave approved scope, Meepo blocks the transition.

Core Artifacts

  • meepo_transition_packet.json: the approval-scoped packet for one transition.
  • meepo_revalidation_result.json: the latest checkpoint decision.
  • meepo_transition_audit.jsonl: append-only audit events for packet creation, approval binding, and revalidation.
  • Optional lane directories such as data/meepo/rubick/, data/meepo/roshan/, data/meepo/naga/, and data/meepo/memory/ may store lane-specific copies.

Checkpoints

Meepo supports these eight checkpoints:

  1. before_draft: before a lane drafts a proposed transition.
  2. after_context_assembly: after context is assembled and before approval text is finalized.
  3. before_approval_request: before asking for approval.
  4. after_approval_received: immediately after approval is recorded and bound to packet hashes.
  5. before_execution_submit: before any executor, publish adapter, or mutation lane receives work.
  6. after_execution_result: after bounded execution returns evidence, before state is trusted.
  7. before_state_commit: before writing durable state such as settings, ledgers, or memory.
  8. after_validation: after validation evidence is checked and before final status is promoted.

Unknown checkpoints fail closed.

Adapter Pattern

Meepo stays lane-neutral. Lane adapters translate local lane state into a normalized TransitionPacket.

Reusable concepts:

  • TransitionSubject: lane, subject id, target, action, and identity.
  • TransitionCheckpoint: the lifecycle boundary being checked.
  • TransitionPacket: the approval-scoped transition artifact.
  • TransitionContextHash: hashes for policy, context, mutation, posture, rollback, validation, authority, and output boundary.
  • TransitionRevalidationResult: the checkpoint decision.
  • TransitionAdapter: a lane normalizer that builds packets and current contexts.
  • TransitionAuditEvent: append-only audit event data.

Adapters own lane vocabulary. Meepo owns comparison, result states, artifacts, and audit. Meepo does not execute Roshan, publish Naga packets, mutate Rubick settings directly, write LifeVault memory, plan work, route requests, evaluate policy from scratch, or manage approvals.

Result States

Meepo returns:

  • consistent
  • stale_approval
  • context_changed
  • target_changed
  • policy_changed
  • runtime_posture_changed
  • rollback_invalid
  • validation_plan_changed
  • authority_changed
  • output_out_of_bounds
  • fail_closed

Concise renderers should use messages such as:

  • "Meepo revalidated this transition. Approval still matches current state."
  • "Meepo blocked this transition because the target changed after approval."
  • "Meepo blocked this transition because the expected output left the approved boundary."
  • "Meepo blocked this transition because policy changed after approval."

Raw or evidence mode may expose packet ids and hashes.

Current Status

Rubick apply is implemented. Rubick settings changes create Meepo packets at proposal time, bind approval ids after approval, and revalidate before snapshot mutation.

Roshan, Naga-Siren, and memory promotion adapters are scaffolded and experimental. They can create normalized packets and perform read-only revalidation tests, but this pass does not execute Roshan, publish Naga content, or write memory.

Future Tinker integration should use the same adapter pattern for development and mutation lanes without redesigning Meepo.