A proposal is a candidate, not a rule. In 0.9.0, MCP producers can submit proposals, but only a person using the mneme decision CLI can accept or reject them. Acceptance creates a canonical project-memory decision; it does not activate protection.

Workflow guide · mneme-hq 0.9.0

Review the decision before it becomes authoritative.

Mneme separates systems that suggest architecture from the human action that adopts it. The proposal store preserves candidate text and provenance; the authority CLI makes the lifecycle transition explicit.

By Theo Valmis·Published September 2026

The released workflow

01Producer proposesAn agent or architecture tool calls decision.propose or decision.propose_batch.

02Mneme storesThe candidate enters the MCP proposal store with status proposed and informational provenance.

03Human decidesA person inspects the proposal, then runs mneme decision accept or reject.

04Consumers continueAccepted decisions materialize into project memory for existing surfaces such as Architecture Audit.

producer / agent
  -> MCP proposal
  -> .mneme/decision_proposals.json
  -> human review
  -> accept or reject
  -> .mneme/project_memory.json
  -> Audit and other existing consumers

The proposal lifecycle is proposed -> accepted or proposed -> rejected. Accepted and rejected are terminal states. Repeating the same successful authority action is idempotent; an illegal terminal transition fails closed.

Inspect proposals

mneme decision proposals

mneme decision proposals
mneme decision proposals --proposals path/to/decision_proposals.json

Lists proposals in deterministic store order. Each row shows stored status, proposal ID, title, producer name/type, source reference, and the accepted decision ID when one exists. An empty store prints (no proposals).

mneme decision show <id>

mneme decision show dprop-example
mneme decision show dprop-example --proposals path/to/decision_proposals.json

Shows the stored proposal: status, title, statement, rationale, scope hints, architecture context, related decision IDs, proposal time, accepted decision link, and all submitted provenance fields.

Provenance is informational. The CLI labels producer provenance as submitted information. It is not trusted evidence, verified execution, or proof that the candidate should be adopted.

Accept a proposal

mneme decision accept <id>

mneme decision accept dprop-example

# Explicit paths and optional human-assigned canonical ID
mneme decision accept dprop-example \
  --proposals .mneme/decision_proposals.json \
  --memory .mneme/project_memory.json \
  --decision-id arch-storage-standard

Acceptance delegates to Mneme's authority service. It records the accepted state and stable accepted_decision_id, atomically materializes the canonical decision in project_memory.json, reloads it, and verifies both runtime and canonical representations before reporting success.

Argument	Meaning
<proposal_id>	Required proposal ID, normally beginning `dprop-`.
--proposals	Proposal-store path. Default: `.mneme/decision_proposals.json`. It must already exist.
--memory	Project-memory path. Default: `.mneme/project_memory.json`.
--decision-id	Optional explicit canonical decision ID. Without it, Core derives a deterministic ID from proposal identity.

Acceptance is not protection activation. A newly accepted proposal becomes an active decision in project memory with no typed rules, test evidence, or protection state added by acceptance. Run the protection workflow separately when deterministic enforcement is appropriate. Acceptance also does not run the Architecture Audit.

Reject a proposal

mneme decision reject <id>

mneme decision reject dprop-example
mneme decision reject dprop-example \
  --proposals .mneme/decision_proposals.json

Rejection changes the proposal to the terminal rejected state. It does not create or modify a decision in project memory. The command accepts --memory because the released authority service constructor requires the path, but rejection itself performs no memory access.

Preserving rejected proposals keeps the review history visible and prevents the producer from turning a rejected suggestion into authority through another protocol call.

Exit codes and failure behavior

Exit	Meaning
0	Successful fresh, repeated, or recovered accept/reject; successful inspection.
1	Core authority refusal or another fail-closed authority error.
2	CLI input/store error, including an empty proposal path, missing or corrupt store, or unknown ID supplied to `show`.

Authority failures are printed as ERROR: messages without a stack trace. Missing or corrupt proposal stores are errors; the authority CLI never falls back to an in-memory store.

Known limitations in 0.9.0

Accepted decisions and MCP canonical reads: acceptance materializes a decision into .mneme/project_memory.json, where existing runtime and Audit surfaces can read it. That runtime ledger is not yet automatically unified with the MCP server's canonical-read path, which is built only from an explicit --adr-dir.

Restart after external authority actions: a running MCP process does not automatically observe an accept or reject performed by a separate CLI process. Restart the MCP process to reload durable proposal state.

Mneme reports missing canonical links honestly. It does not fabricate a canonical MCP record, add a hidden --memory input, or watch the proposal file for changes in this release.

The standards landscape explains why protocol interoperability and governance authority remain separate concerns.

After acceptance

An accepted decision is ready for existing Mneme consumers, including Architecture Audit. Audit can determine whether the decision is already protected, ready for a deterministic guardrail, requires modelling, or remains guidance. That classification is downstream of acceptance; neither the producer nor MCP assigns it.

If the decision should block incompatible changes, use Setup and Protect to validate and install an appropriate typed rule. Keeping these steps separate ensures that adoption of architectural intent is not confused with activation of an enforcement mechanism.

Operator referenceMCP server and tool reference

Install, configure, and inspect the frozen six-tool surface.

Next stepSetup and Protect

Validate and activate deterministic protection separately.

Downstream consumerArchitecture Audit methodology

How accepted decisions are assessed without changing them.

Release proofmneme-hq 0.9.0

The published decision-authority CLI contract.