MP-22 · Verified Memory Write Gate

MP-22 is the third formally packaged Harness Engineering lab. It turns Chapter 8 into a repeatable build–break–measure–defend exercise.

Outcome

You will produce a content-addressed report containing:

• one accepted principal semantic memory;
• exact policy, proposal, grant, evidence, and conflict identities;
• one verified MemoryRecord;
• nine mutation outcomes;
• a reproducible receipt;
• an independently hashed artifact.

Run the reference

cd rust/rust-ai-engineering
cargo test -p mosaic-harness memory_write
cargo run -q -p mosaic-harness --example verified_memory_write_lab

Artifact:

target/labs/mp-22/f90fe7e63e338b488e1e89a3f28d6ce8ab528aec3151e42fe31f440100e2ce5c.json

Expected:

baseline               accepted
mutations              9 / 9
artifact bytes         3,482
artifact SHA-256       251fedcd8aa2d1137df117a40b6e1724cfc71a455532a461e6980f92e08d8f38

Predict

Read all fixtures before execution. Predict the exact result for valid write, missing consent, unsupported source, missing judgment, expired grant, excessive retention, contradiction, tenant drift, and receipt tamper. Explain why incomplete evidence differs from explicit non-support.

Trace

Trace source-user-confirmation through proposal sources, exact judgment digest, evidence coverage, accepted record, write receipt, and serialized artifact. Then trace tenant and policy through policy, grant, proposal, accepted record, and receipt.

Build this acceptance table before changing code:

Case	Decision layer	Expected result	Durable write
Valid proposal	all gates	accepted	one record + receipt
Missing consent	authorization	consent_required	none
Unsupported source	evidence	unsupported_evidence	none
Missing judgment	evidence coverage	incomplete_evidence	none
Expired grant	authorization time	grant_expired	none
Excessive TTL	retention	retention_exceeded	none
Contradiction	conflict	unresolved_contradiction	none
Tenant drift	scope	tenant_mismatch	none
Mutated receipt	replay verification	receipt_mismatch	none

The last case attacks a stored artifact rather than the original decision. Keep those failure surfaces distinct: a decision can have been correct while its persisted proof was later corrupted.

Implement

Choose one extension:

• purpose-bound grants;
• consent revocation time;
• atomic supersession generations;
• structured claim conflicts;
• durable index-publication outbox;
• deletion receipt across primary, vector, lexical, and cache stores.

Add ordinary, boundary, failure, and mutation tests. Update the report identity.

For a purpose-bound grant extension, require the policy, grant, and proposal to agree on purpose. Add tests for exact agreement, policy-allowed/grant-denied, grant-allowed/policy-denied, unknown purpose, and digest mutation. For a deletion extension, use an idempotent generation-fenced acknowledgement per store and prove that a stale index worker cannot resurrect revoked data.

Break

Temporarily remove the support rejection. The unsupported-source case must fail. Restore the gate and keep a regression. Then render accepted memory as a developer instruction and verify that the authority tests catch the escalation; repair it as model-generated data.

Measure

Generate 1, 8, 32, and 64 sources/conflicts. Record latency, allocations, receipt bytes, coverage lookup cost, and conflict scan cost. Explain where database and verifier calls dominate.

Save the machine-readable rows, the build profile, CPU/OS identity, fixture digests, and commit or source-tree identity. Report medians and tail values rather than one run. Separate pure in-memory gate time from source-verifier, consent-store, conflict-query, transaction, and index-publication time. An optimization is valid only if all mutation and receipt checks still pass.

Defend

Review:

• Why cannot the proposer authorize itself?
• Can a trusted-tool echo launder origin?
• What happens after consent withdrawal?
• How are simultaneous corrections serialized?
• Which stores acknowledge deletion?
• Which categories should never persist?

Failure investigation

Symptom: a revoked preference still changes responses.

Inspect write receipt, primary status, deletion outbox, vector and lexical generations, cache keys, read receipt, context manifest, and provider request. Identify the first stale stage. Do not patch it with prompt text.

Write the incident as:

expected invariant
first divergent artifact and generation
why the existing check missed it
containment
code/test repair
data repair
proof of non-recurrence

Your proof should include one regression that recreates the stale stage and one reconciliation run showing no remaining readable or indexed copy.

Evidence to submit

• unchanged reference artifact and its SHA-256;
• your extension diff and updated contract description;
• ordinary, boundary, failure, and mutation test output;
• an adversarial fixture that would pass a prompt-only defense;
• benchmark JSON and a short interpretation;
• one failure investigation;
• a diagram of primary state, outbox, indexes, revocation generation, and receipts;
• a reviewer note stating what the implementation intentionally does not guarantee.

Completion rubric

A complete submission includes:

• fifteen focused tests and nine mutations;
• exact report artifact and digest;
• one extension with four test classes;
• a measured scaling table;
• the failure investigation;
• a security/design review;
• all workspace, dependency, and site gates passing.

Score each dimension 0–2: contract, implementation, tests, measurement, investigation, and security reasoning. A zero in contract, tests, or security reasoning is an automatic revision. Full completion requires at least 10/12 and no zero.

Continue to Chapter 9 only when every rejection is explainable from exact inputs.