Modules and the knowledge map

A Module is a named, versioned assertion about how one part of your organization should work now.

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.

Keep a Module narrow enough that one owner can review it as a coherent decision boundary. Split unrelated knowledge into separate Modules.

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 knowledge map

The map shows the Modules you can access and their dependency relationships. Use it before creating a Module to find an existing owner or foundation. Use it after a change to verify that the new relationship matches the intended knowledge structure. Follow Turn your agents into experts for a complete example.

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.

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.