NAOME

An Autopoietic Software OS for autonomous, proof-driven software evolution

Naome is a deterministic transactional system

Naome treats software development as a deterministic transaction graph. A user intention is converted into a scoped task and a change transaction, executed in isolation, and only applied when the kernel can prove every transition is valid. This turns repository changes from ad-hoc edits into verifiable state transitions. For the full execution lifecycle, it connects directly to Kernel Thesis and Process Pipeline, while the safety envelope is defined in Policy & Gates.

The software OS thesis in one line

The first principle is simple: the repository is not merely a project folder, it is an operating system with durable state, policies, and execution rules. The kernel owns system state; everything else can improve throughput, but never replaces these guarantees. See the section Kernel Thesis for the formal boundary model.

Why software must become self-repairing, not self-documenting

As systems grow, manual review memory and informal notes are not enough. Naome captures evidence, failures, and architectural decisions in structured form, so future tasks can recover from regressions without relearning the same context from scratch. This is how long-running agent collaboration stops regressing over time. The practical loop is explained in Knowledge & Operations and linked to release safety in Current State.

Autonomy only works with deterministic proofs

Autonomy is not about removing gates; it is about replacing uncertain human judgement with reproducible proof. Background receipts, gate results, and context-aware constraints become machine-readable facts. When those facts become stale or fail, progress pauses and the system recovers deterministically. See Proof Foundation for the evidence contract and Policy & Gates for the boundary logic.

How kernel, context, and gates compose safely

Kernel, context engine, and gate runner form one control loop: the kernel defines the state contract, context limits what is relevant, and gates validate the change before merge. That loop is what allows agents to propose diffs while the repository remains auditable and recoverable. For concrete mechanics, continue to Kernel Details and cross-check with Stack & State.

The core thesis: the kernel is state, everything else is an adapter

A deterministic transaction machine, not a clever patch writer

At the center of NAOME is a deterministic transaction machine that controls scope, transitions, and proof obligations. Agents can generate a patch candidate, but the kernel executes the formal process: isolate work, validate invariants, and only allow merge when every transition is proven valid. For concrete state semantics, connect this with Kernel Details and Policy & Gates.

Human intent becomes a structured specification

A user idea is never executed directly. It is first translated into a GoalSpec, then decomposed into TaskSpecs with explicit constraints, required artifacts, and accepted scope. This prevents ambiguity and gives the system a stable contract for planning, gating, and auditing. It is the first gate in the workflow described by Process Pipeline.

Only the kernel is allowed to change system state

The kernel is the only component permitted to write the foundational state. Agents remain external contributors of proposals; they cannot commit directly to the source of truth. This keeps provenance and rollback behavior deterministic, even when many tasks run in parallel. For the practical impact of this rule, see Current State and Policy & Gates.

Git, Codex, and IDEs remain replaceable adapters

Git, Codex, IDEs, CI, and external helpers can accelerate execution, but none of them are required for the OS semantics to exist. NAOME stays operational if adapters are swapped, because policy, transaction control, and evidence handling are native to the kernel. This design follows the dependency model outlined in Stack & State.

Foundation as source of truth and invariant keeper

The foundation layer is where the authoritative branch history, accepted invariants, and release safety contracts live. Everything above it is convenience: UX, tooling, model context, or agent orchestration. The architecture is intentionally strict so that convenience never overrules correctness. For how this affects release publishing, see Policy & Gates and Current State.

Roadmap architecture: from V0 foundation to V1.9 platform layer

V0: Foundation Scaffold

V0 establishes the minimal operating floor: source registration, deterministic hashing, snapshot capture, and a local event store. The kernel learns a reproducible baseline state for each folder (revision, file graph, file sizes, hashes), and all observed activity is written as append-only events. In this phase NAOME is still non-invasive: it validates scan integrity and policy configuration, but it does not yet claim production control over repository changes. This base maps directly to the implementation sequence in Build Phases and to today’s guarantees in Current State.

V1.4.19: Background Proof Foundation

V1.4.19 is where verification changes from status flags to auditable receipts. Every gate run produces structured artifacts (command, args, env hash, exit code, duration, stdout/stderr references, and freshness state), and the kernel uses those artifacts to decide whether a task is still safe to continue. This removes the dependency on repeated human-like re-checking in foreground loops and gives background agents a canonical proof protocol to consume. Tie this to implementation in Proof Foundation and governance in Policy & Gates.

V1.5: Context and Architecture Hardening

V1.5 focuses on controlled execution quality: context is no longer a simple file list, but a bounded neighborhood defined by scope rules, known dependencies, and relevant tests. Architecture checks gain stronger predicates, and failure events are typed so recurring error patterns trigger stronger countermeasures. High-risk scopes, buggy task histories, and weak proof states are blocked earlier through stricter gate and approval policies.

V1.6: Multi-Worktree Sessions

V1.6 introduces reliable parallelism without chaotic merges. Each task gets an isolated worktree, scoped branch state, and isolated runtime artifacts; shared execution is coordinated by a central scheduler with per-lane priorities (quality, compile, tests, heavy, release). A conflict classifier (`safe`, `caution`, `blocked`) then decides when tasks can run concurrently and when one must wait.

V1.7: Deterministic Local Git OS

V1.7 turns local concurrency into deterministic integration rules. Instead of implicit branch ordering, NAOME uses a local merge queue with rebase/simulation, stale-task invalidation, and explicit dependency checks before merge. Security, recovery, and architecture validity are enforced before feature throughput, so the remote branch stays linear even if local work is highly active.

V1.8: Public Release Flow

V1.8 defines the external contract of the platform: local execution can be rich, noisy, and deeply parallel, while published Git history stays deployable and comprehensible. Internal tasks may generate many commits, but only curated release snapshots are promoted to `next` and then fast-forwarded to `main` after safety checks pass. This enables clean audit trails, predictable rollback boundaries, and a practical CI-facing history.

V1.9: Repo-native knowledge graph

V1.9 adds structured project memory as part of the repository surface, replacing raw chat transcripts as long-lived project state. Knowledge is separated into typed nodes (decisions, concepts, constraints, risks, tasks, patterns) and relationship edges (depends-on, supersedes, proven-by). Agents receive compact, ranked context instead of unbounded history, which raises relevance and lowers prompt drift. The same continuity goals are elaborated in Knowledge & Operations.

V2: Autopoietic Factory Kernel & Self-improving Agent Fabric

V2 is the full operating-system phase where the factory continuously runs and manages itself under explicit constraints. Recovery, resource governance, and conflict mediation are handled continuously, while execution remains deterministic and explainable. At this stage, the self-improving fabric closes the loop: memory ranking, task outcomes, and proof strength feed back into context selection so future work is planned with better priors. See Knowledge & Operations for long-term continuity and Build Phases for transition sequencing.

V1.4.19 and beyond: proof-first execution

Background Proof Foundation: receipts before status flags

The first milestone of this layer is to remove ambiguity in gate outcomes. Instead of treating checks as opaque booleans, NAOME records a receipt per execution with structured inputs: command, environment, timing, outputs, and dependency state. A task becomes trustworthy only when the receipt is fresh, complete, and attributable to the same base revision.

Dark Factory: detached quality and release proofing

The Dark Factory keeps quality verification off the foreground path. It runs quality, compile, test, and release checks in controlled lanes with resource caps and isolation boundaries. This makes daily development faster and more predictable while still producing stronger proof density for any pending merge. For lane semantics and recovery behavior, compare Naome Roadmap and Policy & Gates.

Multi-Worktree Sessions: isolated parallel development

Multiple tasks can progress in parallel without contaminating each other when each task is mapped to an isolated worktree with separate runtime state. NAOME tracks overlap by scope and module surface, and can raise `caution` or `blocked` for unsafe concurrent edits before any merge risk materializes.

Deterministic Local Git OS and merge scheduling

Merge planning becomes deterministic logic, not social convention. The local Git layer keeps a queue model, verifies base freshness, and re-checks integration assumptions before promoting work. If a dependency or base revision changed, the lane is recalculated instead of assuming previous validity.

Public Release Flow: main/next as trusted history

The remote surface is intentionally minimal: local execution can be rich and exploratory, but `main` and `next` remain clean, reviewable states. NAOME publishes release-candidate snapshots only after full proof convergence and explicit promotion criteria so release history remains linear and operator-friendly.

Repository-native Knowledge Graph as long-term memory

In this phase, learnings move from ephemeral notes into structured repository state: stable decisions, constraints, proven tasks, known failure patterns, and policy exceptions. The knowledge graph does not replace engineering judgment; it makes relevant judgment much cheaper to retrieve under bounded context. Implementation details appear again in Knowledge & Operations and are expected in later roadmap execution.

How the V1 kernel proves every change before merge

Minimal kernel modules and invariants

The V1 kernel is intentionally small and composable: `naome-core`, `naome-store`, `naome-source`, `naome-vcs`, `naome-policy`, `naome-gates`, and `naome-daemon` each own one contract and never leak mutable state across module boundaries. Invariants are enforced at every API boundary: one source of truth for state, deterministic transitions, bounded outputs, and no silent mutation of source without accepted proof. For module boundaries as part of the broader implementation path, see Stack & State.

Factory state machine lifecycle and recovery

The factory lifecycle is explicit (`Stopped`, `Booting`, `Running`, `Degraded`, `Recovery`, `ShuttingDown`). Each transition is observable and recoverable: boot verifies prerequisites, running schedules background work under constraints, degraded pauses risky operations, and recovery rebuilds state from persisted evidence before work resumes. This lifecycle is consumed by Process Pipeline and linked to operator expectations in Current State.

Transaction state machine and hard transition guards

Transaction flow is not a sequence of comments; it is a machine with hard gates: created, planned, worktree started, agent run, patch captured, patch validated, gates executed, merge decision, merged/failed/aborted. Each move requires explicit preconditions, so incomplete, stale, or unvalidated states are rejected before they can corrupt project state. For practical examples, pair this with the step-by-step flow in Process Pipeline.

Domain objects: SourceFolder, Snapshot, GoalSpec, TaskSpec

`SourceFolder` captures ownership and repository baseline, `SourceSnapshot` captures hash and revision provenance, `GoalSpec` carries intention with constraints, and `TaskSpec` scopes execution (`allowed_scope`, `expected_outputs`, required gates). This separation keeps meaning from execution: a user request becomes durable, inspectable state rather than ephemeral context. It is the same object set referenced in Process Pipeline and in the rollout sequencing of Build Phases.

Patch Envelope and deterministic merge decision

Agents return diff proposals indirectly, but the kernel computes a `PatchEnvelope` from the actual worktree diff so it can verify changed files, hash lineage, and base revision alignment. Merge is deterministic: all required gates must pass, invariants must hold, and stale or unsupported state cannot be merged regardless of whether the patch appears plausible. For merge governance, follow Policy & Gates and the patterns in Naome Roadmap.

Event-sourced auditability without hidden side effects

Every state transition emits events with sequence ordering and source identity: starts, scans, patch captures, gate runs, approvals, merge outcomes, and failures. This enables deterministic replay, forensic inspection, and exact reproduction of decisions across environments while preventing hidden side effects from bypassing the ledger. See Current State for what is already reproducible today.

Why agents create diffs but never own state transitions

Agents are execution assistants, not state authorities. They can suggest edits, but only the kernel applies the state model, validates receipts, and commits the transition. This architecture preserves auditability and makes behavior robust under parallel tooling, because external writers can propose work without changing the trust boundary. For how this principle appears in day-to-day use, see How to use it.

How intent becomes a reproducible, reviewed change

User intent → GoalSpec

The pipeline starts with a durable intent capture step. A user request is normalized into a `GoalSpec` with explicit success criteria, constraints, risk flags, and scope hints. This avoids conflating one-off natural language commands with actionable execution instructions. The intent model is the first practical proof of the principle in Kernel Thesis.

GoalSpec → TaskSpec

`GoalSpec` is decomposed into bounded `TaskSpec` units with required outputs, forbidden paths, expected evidence, and lane assignment. The purpose is to make execution atomic: each task can be executed independently and judged against strict success conditions. Task decomposition is enforced by the same boundaries used in Policy & Gates.

TaskSpec → Transaction

For each task, NAOME creates a transaction with base revision, allowed scope, worktree path, gate plan, and policy tags. This transaction is then progressed through immutable checkpoints so no step can be skipped, retried incorrectly, or mixed across unrelated work. The state machine behavior is detailed in Kernel Details.

Agent run with strict output contract

The agent receives only the constrained task contract, not the full system state. Its output contract requires patch paths, summary, test impact signals, and failure reasons where applicable. This ensures the system, not the model, decides whether the work is acceptable. This contract is reinforced later in Policy & Gates and then operationalized in How to use it.

Patch validation and rollback eligibility

Patch validation checks changed files, forbidden scope violations, base revision alignment, gate requirements, and reproducibility. If required protections are missing (for example regression tests for bugfixes), the transaction does not advance and is marked for remediation. Compare this with explicit criteria in Policy & Gates.

Gate execution, evidence capture, and merge policy

Gate execution is deterministic and evidence-first: each gate writes machine-readable result artifacts (`pass/fail`, timing, output path, environment context). Merge decisions evaluate this evidence against policy and approval state, not just superficial success. This is the safety hinge for Current State and Naome Roadmap claims.

Failure capture and failure-driven protection tasks

Failures are elevated into classified events (`compile`, `test`, `scope`, `architecture`, etc.). High-signal failures spawn follow-up protection tasks (tests, checks, rules, architecture constraints) so the same mistake is less likely to recur in the same scope. Learnings from this loop connect directly to Knowledge & Operations.

Technical stack and data model for deterministic behavior

V1 stack: Rust, Tokio, SQLite, Git worktrees

The V1 stack is intentionally minimal and deterministic: Rust for core state logic, Tokio for async scheduling and process control, SQLite (WAL) for local persistence, and Git Worktrees for isolated execution environments. This combination avoids external orchestration servers while still supporting restart-safe, long-running background processes and reproducible proofs. The stack is chosen for local-first reliability, not cloud convenience. This minimal stack is mirrored by the crate responsibilities in Kernel Details and in the execution sequence of Build Phases.

Workspace crate layout for policy, gates, and daemon

Naome is organized as a Cargo workspace with separate crates for core policy, transaction state, store, source model, gates, VCS, daemon runtime, and CLI. Each crate has one responsibility and one contract: the core remains a pure policy-and-state authority, adapters consume and emit artifacts without owning provenance. This separation reduces coupling and allows independent testing, versioning, and replacement of non-core tooling. For the same architectural intent, see the dependency model in Kernel Thesis.

Source model: files, imports, tests, and graph layers

The source model starts with V1-level file snapshots (path, hash, extension, size, language) and progressively gains import edges, test mappings, and ownership boundaries. By V2, the architecture graph introduces dependency and behavior layers, but the early phases prioritize a bounded, cheap-to-maintain model. This allows fast context selection, risk scoring, and scope checks without compromising determinism. Related context-selection behavior is detailed under Process Pipeline.

Event logs, projections, and recovery on restart

All state changes are recorded as append-only events; projections rebuild runtime state, UI views, and scheduler decisions. On restart, the daemon reconstructs factory state, active sessions, lane schedules, and open transactions from persisted events and snapshots. There is no hidden in-memory truth: behavior after reboot is anchored in persisted evidence unless explicit recovery rules intentionally re-run volatile tasks. This persistence posture is also the anchor for Current State expectations and Knowledge & Operations.

Database tables for goals, tasks, transactions, and gates

The initial persistence model includes `source_folders`, `source_snapshots`, `event_log`, `goals`, `tasks`, `transactions`, `patches`, `agent_runs`, `gate_runs`, `gate_results`, `failures`, `locks`, and `memory_entries`. The schema is explicit around IDs, state stamps, timestamps, and relationships so audits, reproductions, and rollbacks remain inspectable. For how these tables evolve, refer to the phased build plan in Build Phases.

Safety constraints, policies, and gate orchestration

Hard policies: no direct foundation writes

The hard policy set defines the trust boundary. The foundation layer is immutable from the outside: agents, IDE extensions, and user-level automation cannot write foundation state directly. Only kernel-managed transactions may alter tracked source state, and every transaction must pass deterministic transition checks (scope, changed files, base revision match, and valid rollback path) before merge. This prevents invisible state drift and keeps every accepted change attributable to explicit policy enforcement. This is the same trust model reinforced in Kernel Thesis and Current State.

Scope, approval, and conflict prevention

Scope policies define what an agent can touch, approval policies define what a human must confirm, and conflict prevention policies manage concurrent contention. V1 starts with explicit allow/deny paths, task risk scores, and path-level lock governance. High-risk scopes (security, payment, auth, infra) can force approval. If two tasks overlap unsafe modules, scheduling shifts to serial execution to avoid semantic races. For execution-level effects, connect this with Current State and the scheduling rules in Build Phases.

Gate classes from format to architecture policy

Gate classes are organized from cheap deterministic checks to expensive semantic checks: format, typecheck, unit, integration, architecture policy, and optionally security, regression, and performance. Required gates must pass, optional gates can be configured by project profile and task class. Every gate run is deterministic, and required arguments (timeouts, command, working directory, required flag, environment hash) are part of the contract before execution. For the sequencing of these gates within a transaction, see Kernel Details and Process Pipeline.

Regression and recovery gates after failures

Failure-aware gate orchestration is a first-class safety mechanism. If a transaction fails, NAOME classifies the failure and upgrades policy for the same scope until protection is proven: missing regression tests, stale proofs, known architecture violations, or unresolved risk flags trigger hardened re-checks. Recovery gates ensure the repository returns to a stable mode before the next integration cycle continues. The preventive loop is expanded in Knowledge & Operations.

Release rules for main and next branch promotion

The release contract is strict: `next` tracks the current validated release candidate and `main` is promoted only when the candidate is deployable and reproducibly proven. Main is not fed by arbitrary agent commits; it receives curated, human-reviewable promotion events with evidence summaries. This yields a clean, linear, auditable history while preserving aggressive local parallelism. See Naome Roadmap for the evolution of this model and Build Phases for how we stage it.

Memory, ranking, and operational intelligence

Context engine v0 through v2 with memory-driven contexts

Context evolves from broad keyword heuristics (v0) to constrained relevance filtering (v1) and memory-weighted neighborhood selection (v2). In v0, context is a practical best-effort map. In v1, it uses scope hints, test mappings, known imports, and risk tags. In v2, the same primitives are combined with history-derived signals so every task starts with a smaller, higher-signal context. This operationalizes the same progression outlined in Process Pipeline and ties into Current State expectations.

Failure memory and prevention loops

Failure Memory turns every rejected transaction into future protection. Failures are classified by type and tied to affected scopes, files, and assumptions. Naome then derives expected mitigations—regression tests, architecture constraints, stricter gates, or additional review requirements—before a similar task can progress again. This converts isolated incidents into systemic learning rather than recurring manual debugging. The ranking behavior is the practical complement to Policy & Gates and Naome Roadmap milestones.

Scheduler priorities and conflict classification

Scheduler priorities combine user urgency, security pressure, recovery need, and conflict risk into a dynamic execution policy. Concurrency rules are explicit: safe scopes can overlap, caution scopes are monitored, blocked scopes are serialized. Conflict classification is updated as evidence changes, allowing active runs to pause, demote, or reschedule before integration risk increases. This prioritization model is mirrored in Build Phases execution sequencing.

Knowledge graph ranking for long-term project memory

Knowledge becomes structured, not archival. Concepts, decisions, tasks, and constraints are stored as graph nodes with explicit links (`depends_on`, `supersedes`, `proven_by`, `caused_by`). Ranking combines recency, relevance to current scope, proof quality, and observed stability so agents get compressed, low-noise context. This supports both short execution loops and long-term project continuity. For the same knowledge model intent, compare the roadmap milestone Naome Roadmap.

What should decay, what should be preserved

Not all memory is equally durable. High-confidence decisions and proven constraints are kept as stable anchors; temporary hypotheses can decay unless reinforced. Aging models reduce noise by lowering weight over time, while persistent blockers, successful proofs, and architectural invariants retain weight. The result is a repository memory that remains true to reality instead of becoming a frozen transcript. This should be read alongside Naome Roadmap for implementation scope.

Phased rollout from kernel proof to first useful releases

Phase 1: kernel types and event store

Phase 1 establishes the proof-bearing model before assistant autonomy. We define core domain types and an append-only event log, then prove that invalid state transitions are impossible. The objective is low-level correctness: kernel contracts, event replayability, and durable state snapshots are in place before any production-facing agent loop is enabled. This foundation aligns with Kernel Details and Current State.

Phase 2: source registry, snapshot, and scan

Phase 2 adds deterministic source awareness. A source folder can be registered, scanned, and hashed into stable snapshots tied to revision metadata. The scanner produces a reproducible project model so later context, gate, and scope decisions are not ad-hoc, but grounded in verifiable file state and explicit configuration. This maps directly to Stack & State and Process Pipeline.

Phase 3: gate runner and deterministic validation

Phase 3 implements gate execution as a repeatable process. Gates receive typed commands, explicit timeouts, and required/optional semantics. Gate results include timing, exit code, and evidentiary artifacts. Merge logic can now reason on proof quality instead of assumptions, and transactions can be rejected deterministically when required checks fail. Pair this stage with Policy & Gates.

Phase 4: transactions without agents

Phase 4 removes agent dependence for first real proof. Human-led patches can be applied in isolated worktrees and run through transaction creation, patch validation, gate execution, and merge decision. This phase validates that Naome's core path works without model intelligence and still enforces the same invariants. See Kernel Details for the mechanics it exercises.

Phase 5: agent adapter and constrained contracts

Phase 5 introduces the agent adapter with strict output contracts and bounded context. Agents become productive contributors, not authorities: they receive only scoped task envelopes, produce patch artifacts, and submit summaries with test impact signals. The kernel remains the final validator and merger. This is implemented through the contracts described in Process Pipeline.

Phase 6+: context and failure memory

Phase 6 and beyond add the intelligence upgrades: richer context engines, failure-memory-derived controls, ranking, and knowledge-driven recovery. These capabilities increase task precision, reduce repeated mistakes, and improve scheduler decisions without weakening deterministic invariants. This progression is the basis for Knowledge & Operations and the roadmap milestone Naome Roadmap.

What exists today and what is intentionally excluded

What is already proven in the repository

The foundational contract is already anchored: source folders can be registered, deterministic snapshots are captured, core transactional types are defined, and the system records event-stream state transitions. Repository models (files, hashes, revisions, event logs) are consistently represented for auditability. This gives Naome a stable base for controlled evolution, even while many higher-level capabilities are still under development. For the concrete execution boundary, compare Build Phases.

Current limits and explicit V1 boundaries

Current V1 boundaries are explicit and intentional: no autonomous full-stack architecture, no blind agent commit flow, no implicit parallel merge behavior, and no speculative memory-only planning. NAOME emphasizes deterministic proof, state safety, and recovery stability over speed. If a safety boundary is ambiguous, execution pauses rather than guessing. This section aligns with the trust model in Policy & Gates.

What is explicitly out of scope for now

Naome intentionally excludes a cloud-native microservice stack, proprietary graph databases, full LLM orchestration infrastructure, and end-user IDE-like abstractions in this phase. It also does not aim for autonomous optimization without explicit policy constraints, and it does not replace existing Git hosting semantics. The core must remain comprehensible and inspectable at the source level. For adjacent scope boundaries, see the phased plan in Naome Roadmap.

Next safe milestones in the implementation plan

The next milestones focus on delivery confidence: expanding policy coverage, strengthening failure-derived recovery actions, integrating deterministic merge queue semantics, and introducing practical context ranking for repeated operational tasks. Each milestone is validated before the next is started so speed remains secondary to trustworthy behavior. These milestones are sequenced in Build Phases.

How to start with Naome and work safely

Initialize and start with a source folder

Start with one registered source folder: the smallest reliable boundary is a clear repository root plus a foundation reference. Run initialization to persist baseline metadata, then verify that the folder and config are recognized before any transaction work begins. Do not skip this step; the entire control plane depends on a correct initial state. This mirrors the setup flow discussed in Process Pipeline.

Understand snapshots, tasks, and transaction states

Think in three layers: snapshot, task, transaction. A snapshot captures reproducible repository state; a task defines what should change; a transaction executes that task through deterministic phases. You should expect explicit state transitions and inspect each state before manual interventions: Created, Planned, Running, Gates, Merge Ready, or Failed. These terms are defined by Kernel Details and orchestrated by Policy & Gates.

Create bounded tasks with explicit scope

A good task is never “fix this page” in the abstract. It is bounded by paths, tests, and success criteria. Define what is allowed to change, what must not change, and what evidence is required before merge. This single step reduces model drift, noisy changes, and rework caused by imprecise prompts. If this feels similar to Kernel Thesis in scope language, that is by design.

Run gates and inspect deterministic outputs

Gates are the first line of safety and the source of trust. Execute lint/typecheck/unit checks with deterministic arguments, verify output logs, durations, and environment details, and review whether each required gate passed for this exact base revision. If outputs are stale or missing, the task is not ready even if it looks locally plausible. You can compare acceptance criteria to Policy & Gates.

Approve only reproducible and review-ready merges

Approval should target the whole task envelope, not an isolated snippet. Require a reproducible receipt set, stable base alignment, and rollback readiness before merging to foundation state. If any requirement is unclear, keep the task in review or recovery state and ask for completion before proceeding. The same safety sequence appears in Process Pipeline and Current State.

Expect rollbacks and memory updates by default

Failure is not an exception in Naome; it is part of the workflow. A failed transaction should produce a clear failure record and derived follow-up protections, then either retry with stronger constraints or route through recovery. This keeps your system moving while preserving confidence: every rollback becomes a learning edge, not silent loss. Those protective loops are operationalized in Knowledge & Operations.