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.

The map does not infer dependencies from repository imports, directory layout, or similar names. A dependency exists only when an authorized Cortex operation records 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.