Modules and the knowledge map

A Module is a named, versioned statement of what is defined for one subject and why. It can hold a product requirement, design principle, architectural decision or working preference that agents need to apply.

Your agent can create and maintain Modules from the work you already do. You do not need to write them or design the graph yourself. The quickstart shows how an ordinary correction becomes reusable knowledge.

Module contents

Each Module contains a durable name, Markdown content, an owner, visibility state, and zero or more dependencies. The name identifies the subject across versions. The content records the current knowledge for that subject.

The agent keeps each Module focused on one subject, updates existing knowledge before creating a duplicate, and preserves the reason behind the decision. You can review its changes or let it maintain knowledge within your instructions and permissions.

Dependencies

A dependency means that the dependent Module requires the other Module to be understood correctly. If an application Module depends on an authentication Module, flashing the application also includes the authentication knowledge.

Dependencies point from specific knowledge toward its foundations. Cortex resolves the transitive closure and emits each Module once. The agent maintains these relationships when it changes the knowledge; the human does not need to connect each Module manually.

The knowledge map

The map shows the Modules you can access and their dependency relationships. Agents use it to find existing knowledge and check that new relationships fit. You can inspect the map whenever useful. Follow How agents grow your knowledge for the full workflow.

Repository instruction files can tell an agent when to flash a Module. Keep durable rules and reasons in Cortex; keep repository-local instructions and current implementation evidence with the repository. Cortex does not infer Module dependencies from imports, directory layout, or similar names. An authorized operation must record every dependency.

Modules state the system; Issues track work to reconcile code and other artifacts with it. A saved Module is not evidence that the implementation already follows it.

Version history

Cortex preserves immutable snapshots when Module content, dependencies, ownership, or lifecycle state changes. The current Module remains the fast read model; version history records how that state changed. Use the CLI version-history commands to list versions, read a snapshot, or compare two versions.