A Mneme-ready decision is an opportunity, not a protection. mneme protect validate proves the proposed rule without writing anything. mneme protect activate installs the typed rule for that one decision — explicitly, idempotently. And only a fresh canonical assessment that observes real enforcement evidence reports the decision Protected. Nothing on this path involves a model.
Protection activation

Mneme-ready is
not Protected.

The audit classifies your architectural decisions. Activation turns one Mneme-ready decision into a real, mechanically enforced guardrail — and the decision only counts as Protected when a fresh canonical assessment observes enforcement evidence in the repository.

The four tiers

The Architecture Protection Audit classifies every active decision into one of four canonical tiers. Activation consumes this frozen classification — it never reinterprets it:

TierMeaning
ProtectedDeterministic intent with verified enforcement evidence.
Mneme-readyDeterministic intent with a concrete safe guardrail identified — an opportunity.
Requires modellingDeterministic intent that needs modelling before it can be a guardrail.
GuidanceNot appropriate for deterministic enforcement.

Mneme-ready means "Mneme knows exactly which deterministic rule would protect this, and none exists yet." It does not mean the decision is protected.

The complete loop

M1.4 closes the first complete Mneme product loop:

Audit → Setup → candidate → validate → activate → canonical verify → Protected

mneme audit classifies. mneme setup initializes project state in setup mode — context and non-blocking checks only, never enforcement. The mneme protect subcommands turn one classified Mneme-ready decision into a real, mechanically enforced guardrail.

The lifecycle is derived, not stored: candidate → validated → activated → verified. No persistent per-decision lifecycle state is created. Final truth is always re-derived from repository evidence: the installed typed rule in the decision's memory record is the enforcement artifact, and the canonical assessment independently observes it and classifies Protected.

The workflow

mneme protect listRead

Lists decisions that are active, currently unprotected, and canonically Mneme-ready. Already-Protected, Requires-modelling, Guidance, and superseded decisions are never candidates, and no model decides eligibility — the audit's frozen classification decides it.

$ mneme protect list --memory .mneme/project_memory.json
mneme protect validateValidate

Runs four deterministic checks through the existing enforcement engine — without writing anything and without enabling protection:

  1. 01
    A prohibited input containing the forbidden token is detected as a FAIL.
  2. 02
    A permitted input is not blocked by the proposed rule.
  3. 03
    Applicability is respected: ordinary artifact paths are enforced and the canonical policy sources (the memory file carrying the rule) stay exempt.
  4. 04
    Unrelated paths are unaffected.
$ mneme protect validate <decision-id> --memory .mneme/project_memory.json

Validation is not activation. A VALID result changes nothing in the repository and moves no audit metric.

mneme protect activateActivate

Activation is an explicit user action. Audit, setup, rule generation and validation never enable protection; only this command installs enforcement. It appends the typed FORBID_LITERAL rule to that one decision's record in project memory — the same artifact mneme check and the agent hooks enforce — and refuses on any unsafe or unsupported state. Activation is idempotent: rerunning does not create duplicate rules.

$ mneme protect activate <decision-id> --memory .mneme/project_memory.json
mneme protect statusRead

Shows the decision's canonical tier, guardrail, evidence, and whether the activation rule is installed — all derived from the repository, never stored.

$ mneme protect status <decision-id> --memory .mneme/project_memory.json

All four subcommands take --memory <project_memory.json> (required) and optional --repo-root <dir> for the same external CI-evidence scan mneme audit performs.

Activation is not verified protection

After activation Mneme does not simply mark the decision Protected. It re-loads project memory from disk and re-runs the same canonical assessment mneme audit uses. Only when that independent assessment observes real enforcement evidence is the activation reported as verified:

Protection activated and verified: [config-format] (rule installed) rule: FORBID_LITERAL "yaml" verification: canonical assessment reports protected

If activation is requested but no enforcement evidence is observable, the decision remains NOT Protected, Current Protection does not increase, and the command says so. The audit score is always a consequence of canonical classification — never edited directly.

Result distinctions — never faked
ResultMeaning
verifiedThe rule is installed (now or earlier) and the canonical assessment observes Protected.
already_protectedThe canonical assessment already observed Protected; nothing is written.
verification_failedThe rule was written but the canonical assessment did not observe Protected: the decision remains NOT Protected (exit 1).
validation_failedValidation rejected the proposal; nothing is written.
not_eligibleRequires-modelling, Guidance, or superseded/inactive decisions cannot be activated. (A decision that is already Protected has its own outcome above.)

Walkthrough

One decision, end to end — the transcript below is the canonical example from the core documentation:

# What can be activated? $ mneme protect list --memory .mneme/project_memory.json Protection activation candidates ============================================================ Protected: 1 Mneme-ready: 2 Requires modelling: 1 Guidance: 1 Candidates: 1 [1] config-format: Use JSON for configuration files guardrail: FORBID_LITERAL: yaml rule to install: FORBID_LITERAL "yaml" applies to: global applicability (canonical policy sources exempt) enforcement: FORBID_LITERAL fails on an exact case-sensitive match, ... # Prove the rule behaves correctly before touching anything $ mneme protect validate config-format --memory .mneme/project_memory.json Validating proposed protection for [config-format] proposal: FORBID_LITERAL "yaml" checks: PASS prohibited_detected: input containing 'yaml' is a typed FAIL PASS permitted_allowed: permitted input without 'yaml' is not blocked PASS path_scope_respected: artifact path enforced=True, canonical policy source exempt=True PASS unrelated_paths_unaffected: unrelated artifact path enforced=True, permitted content blocked=False Result: VALID Validation never activates protection. # Activate (explicit) — verified by a fresh canonical assessment $ mneme protect activate config-format --memory .mneme/project_memory.json Protection activated and verified: [config-format] (rule installed) rule: FORBID_LITERAL "yaml" verification: canonical assessment reports protected Re-run `mneme audit` to observe the new Protected decision. # The audit now independently observes the protection $ mneme audit --memory .mneme/project_memory.json --repo-root .

Boundaries

  • One decision per activation; there is no "protect everything".
  • Activation never overwrites user-authored rules or unrelated configuration.
  • No network, cloud, or model involvement anywhere in the path.
  • Requires-modelling and Guidance decisions are not activatable; converting them is a separate modelling task.
  • Legacy-migrated decisions (from items[] rather than decisions[]) cannot be activated; the command fails closed.
  • Only the canonical proposal shape — a global FORBID_LITERAL token — is activation-ready; scoped rules return unsupported from validation.
Exit codes
CodeMeaning
0Success or desired state.
1Actionable failure: not eligible, validation failed, or verification failed.
2Usage error: missing file, unknown decision id, or refused unsafe record.

Source of truth

This page documents the M1.4 core at MnemeHQ/mneme@91d71be7. docs/protect-activation.md in that repository is authoritative: the four tier names, the four validation checks, and the result distinctions above are the frozen core semantics, quoted — not reinterpreted here.

These subcommands ship in the Mneme core at that commit and are part of the released mneme-hq package on PyPI since 0.7.0. Install with pipx install "mneme-hq==0.7.0" (see the CLI reference).