Introduction

An AI-native org routes every change - a feature, a fix, a doc, an infra tweak, a dependency bump - through one process. That process is not a habit or a team convention; it is written down, and it is the authority the automation implements. Cogitave's own estate works this way, and this module uses its lifecycle as the worked example you can copy for your own org.

A unit of change is a Request: a first-class node in the org's canonical model, addressed by a stable id, just like an Agent or a Doc. (In Cogitave's Core that node reads cogitave://request/{id}.) Humans and agents drive the same Request through the same stages over MCP, so "what state is this change in, and why" is a single query an auditor can answer. Cogitave records the canonical description of those stages in LIFECYCLE.md - this module teaches you to read and use a lifecycle document like it, not to memorise a paraphrase of it.

The one rule to carry in

The lifecycle does not invent policy; it sequences the floor you already learned into auditable stages. The rule that shapes everything else is propose-only:

That is why the whole process has exactly two write tools, and why neither of them can change the world on its own. You will see what they do - and do not do - in the next unit.

What you will get from this module

Not a checklist to obey blindly - a working model of how a change travels from an idea to done: the seven stages and what advances each, why the write tools only propose, and how to read the Definition of Done so you can tell when a Request is genuinely finished versus merely worked on.