A proposal is a candidate, not a rule. MCP producers can submit proposals, but only a person using the mneme decision CLI can accept or reject them. Acceptance writes a canonical decision version into the Decision Index; it does not activate protection.

Workflow guide · mneme-hq 0.10.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.

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 become canonical versions in the Decision Index, visible to MCP reads, mneme check, and mneme audit.

producer / agent
  -> MCP proposal
  -> .mneme/decision_proposals.json
  -> human review
  -> accept or reject
  -> .mneme/project_memory.json (decision_index)
  -> MCP reads, 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.

Keep proposal, execution, verification, and authority separate. The system proposing or implementing a change should not be able to redefine the constraints that judge that change. GitHub documented why this matters when an agent responded to a compatibility failure by applying an escape-hatch label rather than restoring a missing SDK method; human review rejected the waiver and required the implementation to be repaired. See GitHub's lesson to protect the oracle from the agent.

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, writes a new canonical decision version into the Decision Index in project_memory.json (its source evidence records source_type: "proposal"), reloads it, and verifies both runtime and canonical representations before reporting Materialized: yes and Verified: yes. A running MCP server sees the decision on its next read, without a restart.

Acceptance needs migrated memory. On memory without a decision_index section it exits with code 2 and prints the mneme decision-index migrate preview and apply commands; see the migrate reference. The accepted version records when it was accepted, not who accepted it: there is no approver field.

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, unknown ID supplied to `show`, or project memory that has not been migrated to the Decision Index.

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.

What changed in 0.10.0

In 0.9.x, a decision accepted here was not visible to the MCP server, and a running server needed a restart to see an accept or reject. Both are fixed in 0.10.0: the server reads canonical decisions from the Decision Index that acceptance writes to, and it re-reads the proposal file before each read.

Keep every writer on 0.10.0: once memory is migrated, a 0.9.2 or earlier process that writes it succeeds silently and leaves a file that 0.10.0 mneme check then refuses to read. Upgrade CI jobs, hooks, and teammates before you migrate. If it happens anyway, restore the file from version control; decision-index migrate won’t repair it.

Mneme still reports missing canonical links honestly. It does not fabricate a canonical MCP record or watch files for changes.

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 the mneme audit command. It determines 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. The hosted Architecture Audit works differently: it reads files in the repository (ADRs, agent instruction files, docs/ Markdown, and configuration), not project memory, so it sees an accepted decision only once that decision is written into the repository, for example as an ADR.

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 consumermneme audit

How the CLI classifies accepted decisions without changing them.

Release proofmneme-hq 0.10.0

The published decision-authority CLI contract and the Decision Index.