For agents and technical readers

Read, correct and verify memory

Find the authorised source, submit one bounded correction and report the actual proposal state and current wording.

Contents

Compatibility and authority

Use the tools advertised by the intended Mind connection. This procedure describes the released memory tools; a connector may narrow their inputs. The connected principal needs read and propose access to the relevant area. It does not gain approval authority from this page.

Discover and read

  1. Call orient with {}. Verify the intended Mind and principal.
  2. Follow the relevant first_reads map with read.
  3. If needed, call list_files with {"dir":"<authorised folder>"}. The field is dir.
  4. Read the current record. Follow its sources and any superseding record before stating what applies now.

Example input to read:

{"path":"<authorised folder>/decision.md"}

Angle-bracket values are placeholders to replace after discovery. Never infer the contents of a missing or denied record.

Prepare one change

Read the entire current record before replacing it. Preserve unrelated wording and required metadata. For an ordinary record, an edit can target a section; a replacement without a current base can be held. Memory lifecycle entries require the revision/base contract supplied by their read.

The compatibility form below was exercised through the hosted connector. It replaces one ordinary record and can require review. Replace both placeholders with the actual authorised path and the complete proposed text.

{
  "changes": [
    {
      "path": "<authorised folder>/decision.md",
      "content": "<complete corrected record, preserving required metadata>"
    }
  ]
}

Submit that object to check_write first. A passing dry run is not a write and does not reserve the state. With the user's authority, submit the same object once to propose_write, adding a concise rationale explaining the source for the correction.

If the connector advertises typed op changes, use its actual schema. A client validation error before dispatch is different from a service denial or an uncertain submitted write. Do not silently change a submitted request to evade a gate.

Interpret and verify

  1. Require ok: true; retain the returned proposal_id.
  2. For status: "held", report pending review. The proposed text has not landed.
  3. For status: "applied", read the source again and verify the intended change.
  4. For a held proposal, inspect it with get_proposal {"proposal_id":"<returned id>"}. An authorised reviewer checks the exact diff and uses the supported review surface.
  5. After approval, read the source again. Report the readback separately from approval.

An ordinary review card can use act with action: "queue.answer", the returned card_id as item_id, and answer as the JSON string {"decision":"approve"}. This is only for an authorised review. Human approval requests have a separate exact confirmation/content-hash contract; never fabricate that confirmation.

Recovery and cleanup

After interruption, inspect the original proposal and current source before another submission. On a conflict, reread and reconcile. On denial, stop with the missing access and authorised handoff. A rejected proposal is not an applied correction.

Remove only disposable test records, through the supported authorised deletion/review path. Keep the evidence needed to explain any held cleanup.

Verification boundary

The hosted connector completed a synthetic correction through held review, approval and source readback on a development build. This is not independent qualification of fresh Codex CLI or Claude Code sessions or all released installations.

Related

Correct saved information in your Mind · Pilot interface reference

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Read, correct and verify memory

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Find the authorised source, submit one bounded correction and report the actual proposal state and current wording.

[Page as Markdown](https://app.mensara.ai/how-it-works/correct-memory-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/suggest-a-correction)

## Correct memory

Availability: Released proposal and review route; outcome depends on local rules.

Who can do this: Propose access; approval authority is separate

What changes: Creates a proposal that can apply or wait for review.

Verification: Synthetic held/approved/source-readback path observed on a development build; fresh coding-client qualification pending.

## Compatibility and authority

Use the tools advertised by the intended Mind connection. This procedure describes the released memory tools; a connector may narrow their inputs. The connected principal needs read and propose access to the relevant area. It does not gain approval authority from this page.

## Discover and read

1. Call `orient` with `{}`. Verify the intended Mind and principal.
2. Follow the relevant `first_reads` map with `read`.
3. If needed, call `list_files` with `{"dir":"<authorised folder>"}`. The field is `dir`.
4. Read the current record. Follow its sources and any superseding record before stating what applies now.

Example input to `read`:

```
{"path":"<authorised folder>/decision.md"}
```

Angle-bracket values are placeholders to replace after discovery. Never infer the contents of a missing or denied record.

## Prepare one change

Read the entire current record before replacing it. Preserve unrelated wording and required metadata. For an ordinary record, an `edit` can target a section; a replacement without a current base can be held. Memory lifecycle entries require the revision/base contract supplied by their read.

The compatibility form below was exercised through the hosted connector. It replaces one ordinary record and can require review. Replace both placeholders with the actual authorised path and the complete proposed text.

```
{
  "changes": [
    {
      "path": "<authorised folder>/decision.md",
      "content": "<complete corrected record, preserving required metadata>"
    }
  ]
}
```

Submit that object to `check_write` first. A passing dry run is not a write and does not reserve the state. With the user's authority, submit the same object once to `propose_write`, adding a concise `rationale` explaining the source for the correction.

If the connector advertises typed `op` changes, use its actual schema. A client validation error before dispatch is different from a service denial or an uncertain submitted write. Do not silently change a submitted request to evade a gate.

## Interpret and verify

1. Require `ok: true`; retain the returned `proposal_id`.
2. For `status: "held"`, report pending review. The proposed text has not landed.
3. For `status: "applied"`, read the source again and verify the intended change.
4. For a held proposal, inspect it with `get_proposal {"proposal_id":"<returned id>"}`. An authorised reviewer checks the exact diff and uses the supported review surface.
5. After approval, read the source again. Report the readback separately from approval.

An ordinary review card can use `act` with `action: "queue.answer"`, the returned `card_id` as `item_id`, and `answer` as the JSON string `{"decision":"approve"}`. This is only for an authorised review. Human approval requests have a separate exact confirmation/content-hash contract; never fabricate that confirmation.

## Recovery and cleanup

After interruption, inspect the original proposal and current source before another submission. On a conflict, reread and reconcile. On denial, stop with the missing access and authorised handoff. A rejected proposal is not an applied correction.

Remove only disposable test records, through the supported authorised deletion/review path. Keep the evidence needed to explain any held cleanup.

## Verification boundary

The hosted connector completed a synthetic correction through held review, approval and source readback on a development build. This is not independent qualification of fresh Codex CLI or Claude Code sessions or all released installations.

## Related

- [Correct saved information in your Mind](https://app.mensara.ai/how-it-works/suggest-a-correction)
- [Pilot interface reference](https://app.mensara.ai/how-it-works/pilot-interface-reference)

[Join the waitlist](https://app.mensara.ai/#waitlist)