SAIRP entry point — meetLab Docs

System philosophy

SAIRP separates intent, authority, and execution. The three are distinct objects with distinct lifecycles, and the protocol's correctness rests on never collapsing them.

Execution must consume already-verified authority, not infer it. A runtime that derives permission from prose, diagnostics, or prior outputs has merged authority into execution — a category violation that the protocol exists to prevent.

Classification of this document: Operational Entry, non-authoritative for execution permission. It orients readers and points at the canonical artifacts; it does not grant any authority on its own.

II.

Core docs

The protocol is specified across a small set of canonical artifacts. Read them in this order to walk from architecture down through governance into the runtime phases.

docs/00_ARCHITECTURE_PHASE_BOUNDARIES.md — phase boundary definitions
docs/01_governance/ — governance law set (artifact roles, authority lattice, version manifest)
docs/runtime/04_negotiation/00_NTA_USAGE.md — Phase 4 negotiation
docs/runtime/05_agreement/ — Phase 5 agreement and ACK envelope
docs/runtime/06_admission/ — Phase 6 admission and 6.5 handshake
docs/runtime/08_operations/SAIRP_meetLab_Operations_Guide.md — operator surface

For a single-page walk through the runtime phases, see the lifecycle walkthrough.

III.

Build & operations entry

Canonical build entry

make tier0 tier1 tier2 ORCHESTRATED=1

Governed artifacts are promoted under artifacts/ and runtime state under runtime/. Anything outside those roots is not part of the governed surface and cannot be cited as authority.

IV.

Audit reminder

execution taxonomy

Dev-Exec outputs are not governance authority claims. Gate-Exec claims require artifact-chain plus admission evidence. The two paths are not interchangeable, and conflating them in audit produces invalid evidence.

For canonical HALT semantics, reference docs/runtime/07_execution/halt_codes.md.

the chain intent → authority → enforce(event) → PASS | HALT