Who can approve or change a Module, and what happens when rules conflict?

The Module's owner is responsible for the decision it preserves. Cortex separately checks who has permission to save changes. A person or agent with Module edit access can save an allowed update; a request to obtain your approval first is a workflow instruction, not an additional approval record enforced by the ordinary update operation.

Who can make changes

The Module owner has full authority over that Module. The relevant granted roles are:

• Module viewer: Read and Flash the knowledge.
• Module editor: Read and change content and Dependencies.
• Module admin: Manage the Module, its access policy, and its Issues.

Only the owner can transfer ownership. Module admin alone does not grant that capability. Separate Issue roles do not grant permission to change Module knowledge, and a person can receive more than one role.

A child Module can inherit its parent's permission policy. In that case, policy changes belong at the effective permission boundary. Account ownership provides policy recovery authority; it does not provide ordinary reading access to every Module.

If you require approval before agent edits, state that instruction explicitly and choose appropriate Cortex grants and host confirmation settings. Review the exact text and Dependency changes. Allowing an operation in the agent host does not add a missing Cortex permission.

When instructions disagree

First determine which Module owns the disputed decision. Dependencies explain prerequisite knowledge; they do not transfer ownership or establish a general rule that the last text in a Flash wins.

Ask the responsible owner to decide whether the intended rule changed, whether an exception applies, or whether the implementation needs correction. An exception should explain its scope and reason in the Module that owns that subject. Do not silently replace a durable rule with a one-off workaround.

When several owners' decisions are affected, coordinate the exact changes with those owners. Use an Issue for the work required to reconcile the implementation. Keep the Module focused on the lasting decision and its reason.

What history proves

Content, Dependency, and ownership changes create versioned snapshots. History identifies saved knowledge and its author where that information is available. Older Modules may start with an imported snapshot rather than a complete record of earlier edits. It does not prove that a separate human approved the wording or that an agent applied it correctly.

You can inspect earlier versions and use their content as the basis for an authorized new update. A successful update response confirms the save. Restoring an archived Module makes it active again; it is not a command for selecting an arbitrary old version.